Re: [osg-users] Unable to bind a Texture2DMultisample to a StateSet
Thanks very much, Robert! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57975#57975 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Unable to bind a Texture2DMultisample to a StateSet
Hi again Robert and others, I am now getting a glError that occurs in osg::State::applyModeOnTexUnit. It is trying to pass GL_TEXTURE_2D_MULTISAMPLE TO glEnable, resulting in an invalid enum error. I'm working to track down the source of it, but this is code that I'm less-familiar with so it might take a while. I'll keep you posted. Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57976#57976 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Unable to bind a Texture2DMultisample to a StateSet
Yes, Wojtek, you are correct. I habitually used setTextureAttributeAndModes. After changing it to just setTextureAttribute, the error goes away. I am getting a black screen still, but that's probably another issue, as you said. Thanks! Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57978#57978 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Unable to bind a Texture2DMultisample to a StateSet
Shader bug. I was using sampler2D instead of sampler2DMS. Fixed it now, and it works great! Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57979#57979 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Unable to bind a Texture2DMultisample to a StateSet
Greetings, I have a multisampled texture that I've rendered my scene into, and I'd like to attach it to the StateSet of a full-screen quad so I can do some explicit multisampling. Here is the call I am making: Code: fsq-getOrCreateStateSet()-setTextureAttributeAndModes(0, inputTexture, osg::StateAttribute::ON | osg::StateAttribute::OVERRIDE); Where inputTexture is an osg::Texture2DMultisample. Since osg::Texture2DMultisample derives from osg::Texture, it correctly identifies itself as a texture attribute through isTextureAttribute(). However, eventually, StateSet::setTextureMode is called, and this call fails because GL_TEXTURE_2D_MULTISAMPLE is not listed as a possible texture mode in the TextureGLModeSet class (see the top of StateSet.cpp). Should this list be updated to include GL_TEXTURE_2D_MULTISAMPLE or am I doing something wrong? Note: I am using OSG 3.0, but I've checked 3.3 and it is the same. Some background info on why I'm doing this: I'm trying to do explicit multisampling, which allows me to customize how the samples are blended. I already have it working in vanilla OpenGL. Basically the steps are a) render your scene into a multisampled FBO, b) bind the multisampled FBO and render a full-screen quad using a special shader, c) inside that shader, grab the individual samples using texelFetch and then blend them using your own custom blending, d) output the result. It is useful when you need to process the samples in some way before they are blended (e.g., tone map them). If you can think of a better way to do explicit multisampling with OSG, I would be much obliged if you would point me in the right direction. Thank you! Cheers, Frank[/code] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57959#57959 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Unable to bind a Texture2DMultisample to a StateSet
By the way, here is the warning message I'm receiving: Warning: non-textured mode '37120' passed to setTextureMode(unit,mode,value), assuming setMode(mode,value) instead. The value '37120' corresponds to GL_TEXTURE_2D_MULTISAMPLE . I'm not sure if setMode is the desired behavior. I'm only seeing a black screen, but I'm not positive that this is the problem.[/quote] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57960#57960 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgUtil::Optimizer::optimize not obeying Permissible Optimizations for MERGE_GEODES
Greetings! This may be by design, but just in case, I wanted to ask about it. I'm using version 3.0.0, and if I look on Line 282 of osgUtil/Optimizer.cpp, the MergeGeodesVisitor is created. However, the optimizer object (this) is not passed into the constructor, and so the visitor does not have a pointer to the optimizer object. As a consequence, the visitor cannot access the optimizer's _permissibleOptimizationsMap and thus returns true every time isOperationPermissibleForObject is called. The reason I bring this up is that I do want to merge geodes, but I have four geodes in the model that I cannot allow to be merged. I was able to work around this problem by creating my own MergeGeodesVisitor, and that seems to be working well. I just have to remember not to include MERGE_GEODES in my options bit field that I pass into Optimizer::optimize(), and handle it manually myself as I described. Thank you! Cheers, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54046#54046 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question about the correct use of osg::FrameBufferObject
Thank you, Paul and Robert. Just as a suggestion, it may be useful to have a way for NESTED_RENDER ordered cameras to render to a texture. It's my understanding, from looking at the code and from past forum posts, that NESTED_RENDER cameras ignore the camera RTT stuff. I was hoping that attaching an FBO to a StateSet below the camera would be a useful way to compel a NESTED_RENDER camera to switch over to a new FBO. The reason I bring it up is that it would make setting the render order on these cameras brainless -- if camera A needs to render before camera B, then one can simply place camera A as an ancestor of camera B, and not have to worry about setting an explicit render order number. This could be useful for systems that have data-driven pipelines where you have multiple passes over multiple scenes, that are required to happen in a specific order. Thanks again! Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52445#52445 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Question about the correct use of osg::FrameBufferObject
Hi, I'm looking at the source code for osg::FrameBufferObject, and as far as I can tell, I just have to set this as an attribute on a node's StateSet and be done with it? If this is true, then can I use it in conjunction with Nested Render cameras in order to get render-to-texture cameras that render in the order in which they are encountered in the scene graph? Thank you! Cheers, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52399#52399 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Drawing only a specific bin (e.g., the Transparent render bin)..
Hi, I was just wondering if there is any way to draw only a specific bin, either by telling the cull visitor to throw away objects that belong in the other bins, or by somehow influencing the draw process after the cull pass? What I have in mind is deferred lighting, where one often wants to draw only the opaque objects to the g-buffer, and then draw the transparent objects after the lighting pass. Thank you! Cheers, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=51932#51932 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Drawing only a specific bin (e.g., the Transparent render bin)..
Thanks, Christian . I'm only using 7 bits right now, so that solution would suit me just fine. =). -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=51934#51934 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Disabling Checked Iterators and FFP ...Recommended?
Heya, I'm in CMake again, creating a VS2010 solution for OSG v. 3.0.0 (64-bit this time). I have a couple of questions. 1) We have a huge problem with load times in Debug mode. So much so that it's not even worth it to link to the debug libraries because the models (OpenFlight, some of which are huge) take literally hours to load. About 99.9% of that load time is spent in the optimizer, destructing STL containers, and I believe that iterator debugging is the culprit (it's spending a lot of time invalidating iterators, IIRC). We are going to disable optimization during file load (and optimize offline instead), but the question I have here is: do you think it would be okay to check the MSVC_DISABLE_CHECKED_ITERATORS box? I don't even know if this will help; I'm pretty sure that iterator debugging is the real culprit. 2) In CMake, there is also an option to disable the fixed-function pipeline. I am interested in trying this. Will it effectively disable a lot of OSG functionality? 3) I'm looking for options here to create x64 build configurations, but I'm not seeing them. The only x64-specific thing that I've done is download the 64-bit pre-built dependencies. Is there anything else that I have to do? Thank you! Cheers, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47581#47581 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Possible memory growth issue with sorted Particles
Certainly! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46016#46016 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Possible memory growth issue with sorted Particles
Thanks Robert, It looks like, when the particles are sorted, dead particles are given a depth of 0 so that they are automatically placed at the beginning of the list. This will be useful, I think, because it looks like the purpose of the _deadparts stack is to keep track of which particles are dead, so that when the ParticleSystem wants to reuse a dead particle, it doesn't have to do a linear search through the particle list to find them. However, if I know that the dead particles (if any) are at the beginning of the list, then I can just take a look at the first item on the list. If it's dead, resurrect it. Otherwise, create a new one. So I might try subclassing ParticleSystem and overriding the CreateParticle method. In it, I'll check the sorting mode. If it's NO_SORT, then I'll use the _deadparts stack as usual. Otherwise, I'll just check the first particle in the list to see if it's dead. I won't have a chance to try this for a few hours because I have to run off to school, but I will let everyone know how it works out. Thanks again, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45987#45987 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Possible memory growth issue with sorted Particles
Hi Everybody, The above workaround seems to work pretty well. However, it is necessary to give dead particles a depth of -FLT_MIN so that they don't get sorted behind particles that are behind the camera (and thus have negative depth). Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46004#46004 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Possible memory growth issue with sorted Particles
Greetings, I am having some difficulty with the osgParticle classes, and I was wondering if someone could give me some advice. It seems that whenever I choose a sorting mode for the particles other than NO_SORT, I get a particle list that grows unbounded. In a normal situation, the particle list should grow at first, and then stabilize as dead particles get reused. So, for example, if I set the particle effect to emit at a rate of 100 particles per second, and I give the particles a lifetime at 1 second, then over the course of the first second, I should see the particle list grow from 0 to 100. At that point, particles should start dying at about the same rate as they are being created, and so the list should stabilize at 100-105 (allowing some buffer because the world isn't perfect). And indeed, this is exactly what I see when the particles aren't sorted (I created a DebugParticleSystem subclass that prints out the particle list counts, and other info, each frame). However, when I set the sorting mode to SORT_FRONT_TO_BACK, then I get this weird behavior where the particle list grows and grows and grows and never stabilizes. Looking at the code, I think I have a hypothesis, but it isn't complete. Basically, after the particle list is updated, the list then gets sorted. This is an in-place sort on a vector of Particle objects, which has the effect (from what I can see) of invalidating the pointers in the _deadParts stack. So, the pointers in the _deadParts stack end up pointing to particles that are still living, and when a pointer from this stack is used to reuse a dead particle, it ends up reusing a particle that is already alive. Now, I'm not exactly sure how this results in a growing particle stack, but my guess is that, in reusing a particle that is already alive, you prevent it from dying on schedule, and so when it comes time to create a new particle, there aren't enough dead ones on the stack to reuse, and so new particles have to be created from scratch. The only thing that gives me pause about this explanation is that, after a Google search, I was not able to find anyone else who is having this same problem. So, I am pretty sure that I'm doing something wrong here, but I'm not sure what. Thank you! Cheers, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45953#45953 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Using custom shaders with osgParticle
Hi, I need to render the particles using a custom shader that includes a special lighting system that I'm using. If I can just get the Particle System to pay attention to the shader that I wrote, I think everything will be dandy. However, I am having some trouble with this, and I am hoping for some insight. In order to test this, I wrote a simple shader program with a fragment shader that outputs the color red. There is no vertex or geometry shader. This way, if I'm using the shader program correctly, I should see flat red particles. If I'm using the shader program incorrectly, depending on the problem, I'll either see black particles, or invisible particles, or perhaps particles that look as if they're being rendered without shaders (i.e., how they looked before I embarked on this task). The first thing I tried is to simply follow the osgparticleshader example, without using my red shader at all, just to see if I could get particles working with shaders. Unfortunately, if I call setDefaultAttributesUsingShaders, the result is invisible particles. After much debugging, I discovered that I can get the particles to come back if I call setUseVertexArray(false). So, I think there is something that it doesn't like about using vertex arrays (at least in the context of my program). With vertex arrays disabled, the particle system seems to be using immediate mode draw calls, which I don't mind. However, I can't tell if it's actually using the shader or not, because the particles look the same either way. So, I tried adding my red shader program to the state set, and that did not help. The particles drew normally, as if it was ignoring my program and using the fixed function pipeline instead. I suppose it's possible that the particle system now had two programs -- the one set by setDefaultAttributesUsingShaders and the one set by me. So, to rule out such a conflict, I omitted the call to setDefaultAttributesUsingShaders and instead replaced it with everything the method does (essentially inlining the method myself), with the exception that it uses my red shader program instead of the stock one. Still, however, it seemed to ignore my shader. Can anyone think of what I might be doing wrong? My next step will be to try to accomplish this in isolation in a stand-alone program, but I just wanted to check and see if there are any ideas. Thank you! Cheers, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44648#44648 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rendering ONLY to texture...
Ah, yes. This works fabulously, thanks! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42397#42397 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rendering ONLY to texture...
Thanks guys, that is very helpful. I am having a bit of trouble with this, and I was wondering if you might be able to help. For some reason, my call to glReadPixels seems to be a no-op. That is, none of the memory that my data* points to is actually being overwritten by my call to glReadPixels. I ran the osgscreencapture example using --pbuffer-only and --no-pbo, and that seems to be working fine. The debugger reveals that, inside osg::Image::readPixels, the image data is indeed being written-to as a result of the call to glReadPixels. So, something definitely seems different about my program, although I can't seem to detect any appreciable differences in how I'm setting up my program vs. how osgscreencapture is set up. Here is where I set up my viewer: Code: _viewer = new osgViewer::Viewer; // Init the GraphicsContext Traits osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits; traits-x = 0; traits-y = 0; traits-width = OSGDLL_FRAME_WIDTH; traits-height = OSGDLL_FRAME_HEIGHT; traits-red = 8; traits-green = 8; traits-blue = 8; traits-alpha = 8; traits-windowDecoration = false; traits-pbuffer = true; traits-doubleBuffer = false; traits-sharedContext = 0; // Create the GraphicsContext osg::ref_ptrosg::GraphicsContext gc = osg::GraphicsContext::createGraphicsContext(traits); // Create Setup Camera osg::ref_ptrosg::Camera camera = _viewer-getCamera(); camera-setGraphicsContext(gc); camera-setClearColor(osg::Vec4(1.0f, 0.0f, 0.0f, 1.0f)); camera-setViewport(new osg::Viewport(0,0,OSGDLL_FRAME_WIDTH,OSGDLL_FRAME_HEIGHT)); // Add some scene data osg::ref_ptrosg::Node shed = osgDB::readNodeFile(Shed2.flt); _viewer-setSceneData(shed); // Realize viewer _viewer-realize(); The main difference here is that I'm not creating a new camera and setting it as a slave. I'm just using the main camera that was provided by the viewer. Also, I am not double-buffering (I'll explain why in a sec). Here is where I actually draw a frame and then try to retrieve it: Code: unsigned char imgData[OSGDLL_FRAME_WIDTH*OSGDLL_FRAME_HEIGHT*4]; memset(imgData, 0x00, OSGDLL_FRAME_WIDTH*OSGDLL_FRAME_HEIGHT*4); _viewer-frame(); glReadBuffer(GL_FRONT); GLenum readBufferError = glGetError(); glReadPixels(0, 0, OSGDLL_FRAME_WIDTH, OSGDLL_FRAME_HEIGHT, GL_BGRA, GL_UNSIGNED_BYTE, imgData); GLenum readPixelsError = glGetError(); As you can see, I am zeroing out the memory before I call glReadPixels. After I make the call, the memory is still zeroed out. I've tried other values as well. For instance, if I use 0x0F as my memset value, the array elements remain as 0x0F even after glReadPixels is called. So, it's not even that the frame buffer is empty and I'm getting all zeros or something. Rather, it's just failing to overwrite my data with whatever is in the frame buffer. And yet, I don't get any errors. Both calls to glGetError in the above code return zero. Now, if I attempt to set double buffering on, and I pass GL_BACK into glReadBuffer, this returns GL_INVALID_OPERATION for reasons I don't understand (the back buffer should exist, to my understanding, and I'm not making this call between glBegin/glEnd, and those are the only reasons that the glReadBuffer man page lists as possible causes for GL_INVALID_OPERATION). So, I just turned double buffering off and passed GL_FRONT in instead. This got rid of the GL_INVALID_OPERATION error, but unfortunately I'm still not getting anything from glReadPixels. As another test, I tried using osg::Image::readPixels, just in case it was doing something important that I am failing to do: Code: osg::ref_ptrosg::Image img = new osg::Image; img-readPixels(0, 0, 256, 256, GL_BGRA, GL_UNSIGNED_BYTE); The end result was the same: it allocated itself a data buffer, but glReadPixels fails to fill it in. The entire buffer is just full of 0xCD's. Although I am not creating any PBOs to my knowledge, I tried binding GL_PIXEL_PACK_BUFFER to 0 just in case. However, this did not seem to help. So, I'm thinking that there is something else about the OpenGL state that needs to be set, which I am missing, in order for this to work. Does anyone, by chance, have any ideas?[/code] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42371#42371 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Rendering ONLY to texture...
Greetings, everyone. Is there any way to get OSG into a state where it renders everything to an offscreen FBO? In addition to this, I would need to suppress any sort of window creation or rendering to a back buffer. That's my basic question, but here's a little background just in case. What I am basically trying to do is create an OSG-based C++ library that will: a) Create a render context without launching a window. b) Draw a scene graph to an off-screen buffer. c) Read the pixel data back into system memory. d) Marshal that data into WPF code. e) Paint a WPF control with this image. I know that this is bound to be slow, but frame rate is not important for this application. I already have d e working, using a set of dummy pixel data defined in the C++ library. I just need to figure out how to get OSG to render to an off-screen buffer without launching a window, and then how to get it to do some sort of glReadPixels-type thing in order to get the result into system memory. So far, I've just been using osgViewer::Viewer for everything, but I'm guessing that option is out and that I'll have to do something more manual. Thanks! Frank P.S. I am aware that there are other ways of getting OSG to draw to a WPF control. For instance, I tried using a WinFormsHost in order to stick a WinForms panel into my application. This gives me an HWND that I can pass to OSG so that it will draw directly to the control. I have tried this approach, however in doing so, I have run into some so-called airspace issues that are tricky to solve. I have tried a couple of the approaches that I found on the web for working around this, and none of them are optimal. So, I am giving this method a try, wherein I draw to an off-screen FBO and then read the pixel data back, and pass it to WPF. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42347#42347 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rendering ONLY to texture...
Oh, one more thing. So, I'm sure it's probably not possible to create a render context without having a window of some kind. My guess is that (in Windows, at least), creating a render context requires a Win32 device context, and that getting a device context requires an HWND. So, I suppose my only option would be to create an invisible window. If possible, I think it would be acceptable to create an invisible window, and then just glReadPixels from the back buffer or something. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42348#42348 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Acquiring the world matrix of a DoF node
Greetings, everyone. I figured out what I was doing wrong, and I thought I would post my answer here for posterity. The short answer is: everything is working the way it is supposed to. Nothing to see here. Move along. =) Long answer: The PUT matrix is essentially the inverse of the DoF node's origin. The descendant geometry is not defined relative to the DoF's origin, as is the case with other types of transforms. Instead, the PUT matrix will transform all descendant geometry such that it becomes relative to the DoF's origin. For example. If you have a DoF whose origin is at 0,0,10 (lets leave rotations out of this, for simplicity sake), and you have a geode with a single vertex that is one meter above it (z=up in this example), you may expect (as with other transforms) that the DoF would have a position of 0,0,10 and the vertex would have a position of 0,0,1. However, this is not how it works. Instead, the DoF has a PUT matrix of 0,0,-10 and the vert has a position of 0,0,11. If you transform this vert by the PUT matrix, it becomes 0,0,1 (its DoF-relative position!). At this point, you can apply the DoF position/rotation offsets (if any). Then, you need to transform it back, using the inverse PUT matrix. So let's say that the DoF in our example has a 45degree y-rotation. Here's what happens. The PUT matrix transforms out vert to 0,0,1. Then, we apply the 45-degree rotation, making it 0.7071, 0, 0.7071. Then, the inverse matrix is applied, making the final position 0.7071, 0, 10.7071. Voila. So, the final matrix of a DoF transform is: PUTMatrix * rotationPositionOffsetsMatrix * InvPUTMatrix ...which is exactly what DoFTranform::localToWorld does (which is called by Node::getWorldTransforms). So, naturally, if there are no rotation or position offsets in the DoF (i.e., they are all 0), then the final matrix is going to be identity. But that's okay, because your geometry is not defined relative to the DoF's origin (i.e. its inverse PUT). If you have a chain of DoFs, the final matrix of each (as calculated above) can be concatenated just like any other matrix, and the math works out (I had to see this for myself on the whiteboard before I believed it ... tough to visualize). So, again, long-story-short, it will all work out if you just let it do its thing. If you question it too much, you'll end up on a long journey to reinvent the wheel, as I did. =) Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42223#42223 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgOcean] Syncronizing waves across multiple monitors
Heya, I know that I can initialize the water with the same random seed. However, there does not seem to be a way to synchronize the timing of the waves. Does anyone know if this is possible? If not, I have coded a solution. It's a bit of a hack, but I would be happy to clean it up and submit it as a possible future update. I would prefer to use the canonical source code, rather than my own version of it, and so if the feature doesn't exist, canonizing my changes would be the next best option. =) Hahaha. Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42225#42225 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] Syncronizing waves across multiple monitors
Hello, Yes, you are right. I neglected to mention that these monitors are hooked up to separate machines. =) Your suggestion is much cleaner than my solution, and has the added benefit of not having to be checked into the central repository. I will give that a try. Thanks! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42230#42230 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Loading textures into VRAM
Greetings, My understanding is that most OpenGL implementations will not load a texture into VRAM until the time that it is first used. I was wondering, will a call to glBindTexture suffice for using a texture? If so, could I write a node visitor that just visits every StateSet in my graph, pulls out the texture objects, and calls Texture::TextureObject::bind()? I'm trying to think of a way to preload all of my textures into VRAM so that I don't get a frame rate stutter the first time one object or another comes into view. Thank you! Cheers, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41678#41678 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [3rdparty] Frame Rate Decay w/ SilverLining Integration
Greetings, Sorry for the wall-of-text. I am working on a really thorny issue, and I want to include as much information as possible. I am not sure that this is necessarily an OSG-related bug, but I was wondering if there is anyone here who can provide some insight anyway, because I can get the bug to appear/disappear by changing certain OSG settings, but I have no idea why. Basically, we have an OSG-based app (v. 2.8.3) that is integrated with SilverLining for all of our atmospheric stuff. The problem is that, on some computers, we are seeing a frame rate decay. That is, the frame rate will start off high (180fps or so), and the steadily decrease at a rate of about 2fps/sec. So after 30 seconds, it's running at 120fps. After a minute, it's running at 60fps. And so on. Note: this is only happening on a couple of computers. We've had an opportunity to test this app on 6 different computers. So far, the problem has shown up on 2 of them. On those two computers, the problem only shows up under the following conditions: 1. I'm using SilverLining, AND 2. I'm using the SingleThreaded model, OR the app uses render-to-texture. (the render-to-texture is done by attaching an osg::Texture2D to an osg::Camera, set to PRE_RENDER with a FRAME_BUFFER_OBJECT render target implementation, which is then added to the scene graph) So, if I remove the SilverLining integration, the problem goes away. However, SilverLining in of itself is not a sufficient cause. I know this because I can run a simple app, like the OSG 2.x sample that ships with the SilverLining SDK, and the problem does not appear. However, if I add a simple RTT camera to that sample, the problem shows up. Also, if I set the threading model to SingleThreaded, the problem shows up whether there's any RTT in the scene or not. In our own app, the problem goes away if I use a non-SingleThreaded model AND I disable any features that use RTT (osgShadow, mirrors, etc.). There might be other conditions that cause the problem to show up, but if so, I haven't found them. And again, this only happens on two of the computers, out of the six that we've had an opportunity to try (we'll have an opportunity to test on more computers soon). Part of what makes this bug so devious is that it doesn't happen on every computer, and I'm guessing that reduces my chance of finding someone who has already encountered it and solved it. =P Another interesting fact is, if I change the threading model at runtime (using the 'm' key, thanks to the ThreadingHandler), the frame rate Resets, and then starts decaying again. In other words, the app will start at 180fps or so, and then decay (after a minute or so) to 30fps. Then, if I hit the 'm' key to change to a different threading model (doesn't matter which), the frame rate shoots back up to 180fps and then starts decaying again. I can do this over and over again by hitting the 'm' key. Tomorrow, I'll try to delve into the depths of the OSG and SilverLining code to see if I can find the problem. In the meantime, I would feel silly if I didn't at least throw a couple of messages out there and ask if someone else has already encountered this. Thank you! Cheers, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39067#39067 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] Frame Rate Decay w/ SilverLining Integration
Hi Zonk, The basic configuration for the two computers that are having this problem are: 1) Intel Xeon 5405 2.0GHz CPU, 4GB RAM, Nvidia GeForce X260 GPU 896MB 2) Intel Core i7 2.79GHz, 4GB RAM, Nvidia 9800GT 512MB I'm personally running on a machine with an Intel Xeon 5410 (2.33GHz), 4GB RAM, NVIDIA GeForce 9800 GT 512MB. However, the problem doesn't show up on my computer. So, I'm not sure if the video card is to blame, because I use the same video card as one of the problem computers. Zonk, do you have RTT in your demo by chance? If so, would you mind if I took a look at it? Thank you! Cheers, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39119#39119 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rotating the display
Thank you for your suggestion, Magnus. We have given that a try, and it works great for the most part. We've had some troubles with Windows 7 spontaneously changing our settings back to 0-degree rotation, but it turns out that is probably a hardware problem. Also, our HUD items tend to look squished when we rotate 90 or 270 degrees, because of the aspect ratio change, but I suppose that some of the work that I've already done can work in conjunction with the solution you proposed to fix that problem. I'll have to give it some thought. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35992#35992 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Rotating the display
Greetings, My application is going to be run on different displays, some of which might be rotated 90, 180, or 270 degrees from their typical position. I've basically set things up so that my app reads the screen orientation from a config file, and does what it needs to do to make sure that things look 'upright' if that screen orientation is anything other than 0 degrees. For the HUD, I have an osg::Projection node that is a parent to all of the HUD items. If the screen orientation is non-zero, then the projection matrix that I use contains some built-in rotation, like so: Code: osg::Matrix orthoMat = osg::Matrix::ortho(0, screenWidth, 0, screenHeight, 0.1, 1000.0f); osg::Matrix rotMat = osg::Matrix::rotate(screenOrientationAngle, 0, 0, 1); osg::Matrix finalProjMat = orthoMat * rotMat; Just in case you are wondering: if the screen is rotated 90 or 270 degrees, I also swap the width and height so that my HUD items don't look stretched. I also use a trick to make sure that items appear in the correct place when the aspect ratio changes, but I don't bore you with the details of that. This all seems to work well with one hitch: it seems to mess up the computePixelSizeVector calculation. I'm not quite sure how this calculation works, but when I embed some rotation into my projection matrix, it seems to have the effect of setting the w component of the pixelSizeVector to some huge number, and invariably all HUD items are culled by small feature. I solved this by disabling the small feature culling, but since this is done on the camera, it will probably be global to the whole scene, which is probably not desirable. I'm sure I can find some other way (turning culling inactive for all HUD-related nodes, perhaps). I'd like to do this same sort of thing for the main scene rendering, i.e. set the projection matrix on the camera to its normal projection matrix (using the reciprocal of the aspect ratio if necessary), multiplied by a rotation matrix. However, since running into that snag, I'm starting to wonder if this isn't a terrible idea. =] I have no idea what I might be messing up. =P Thank you! Cheers, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35964#35964 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Drawing items beyond the far plane
Hello, I can tell that my OSG-based app is doing some sort of frustum culling, because if I take the camera to the edge of the scene, and I turn it such that it isn't looking at anything, the frame rate jumps to 500fps. However, when I turn back around to look at my scene, the frame rate drops to about 60fps. One thing I found interesting, though, is that this doesn't seem to work for the far plane. If I aim my camera towards the scene, and I pull back until the entire scene disappears beyond the far plane, my frame rate remains at about 50-60fps. Does anyone know why this is happening, and if there is a way to fix it? Thanks, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34841#34841 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Drawing items beyond the far plane
Thanks a lot guys; you are incredibly helpful, as usual. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34846#34846 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Making sure that reflection texture only draws if mirror is visible.
Greetings, I have some mirrors in my scene, which use RTT for reflections. I'd like to make sure that, if the mirror isn't visible, the RTT pass doesn't happen. A simple frustum check should be fine. If the mirror is in the scene camera's frustum, it would be okay to render the reflection texture even if the mirror itself is occluded. So what I have right now is a MatrixTransform node that is the parent of the whole mirror object sub-tree. I give this MatrixTransform a call callback, which renders the reflection texture before traversing to draw the mirror itself. What I'd like to do is add a frustum test here, so I can avoid doing the reflection RTT if the child sub-tree isn't even viewable by the camera. Is this possible? Thanks, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34713#34713 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Making sure that reflection texture only draws if mirror is visible.
Oh, nice, thanks! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34715#34715 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Some texture questions
Hi, I just have some basic questions about textures, and I was hoping someone might have an answer to them: 1) Right now, I have several objects that refer to the same texture file. Is there any way to make sure that these objects, when loaded, share the same texture object in memory, rather than loading the same texture multiple times? 2) It seems as though the system might use a sort of lazy loading scheme for the textures. I'm not 100% sure about this, but when I first load my scene and move the camera around, I notice that there is a frame rate hitch whenever an object is being displayed for the first time. Once I've viewed all the objects at least once, then there are no more hitches. I could be wrong, but I also noticed that some of these objects have non-power-of-two textures, and these hitches correspond with a console message that says Scaling image x from (800,800) to (1024,1024). So, that's why I suspect that maybe the textures are being loaded when they first appear, rather than when the model is loaded. If so, can this be turned off? Thank you! Cheers, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32674#32674 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] Jerky noise map motion
This seems to have spontaneously fixed itself. o_0 -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32333#32333 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgOcean] Jerky noise map motion
Hi, When I run the example, the wave motion looks great, and the demo runs at around 350 frames per second. However, the scrolling normal map seems to move in a very jerky motion, moving in large steps at maybe 4hz. I've stepped through the code, and I'm looking at FFTOceanSurface::computeNoiseCoords. Now, if I comment this code out, and run the example again, the noise texture stops moving as expected. So I think I've found the right place to look. But I can't seem to find what is causing the jerking motion. It looked to me like perhaps there was an issue with mixing ints and floats: some value, like time perhaps, is accumulating, but new accumulations are fractional and are thus being truncated by some implicit integer cast somewhere. Eventually, the value accumulates to the point where a whole number boundary is reached, thus creating a 'pop'. That was my hypothesis, anyway. But I don't see any integers being used as terms in this function. So, it should be creating a nice, smooth motion from what I can see. Has anyone else run into this? Thank you! Cheers, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32111#32111 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Postbuild error with ot11-OpenThreads??
Hi, Sorry to resurrect an old thread, but I am running into a very similar problem: 3file INSTALL cannot find 3 C:/Development/OpenSceneGraph-2.8.3/VS2010/bin/Release/../../bin/ot11-OpenThreads.dll. The OP said that they could find this DLL (and others) in the specific directory. It seems that the OP's problem was that VS didn't have the right permissions to access the destination directory. My problem is a bit different. I'm running VS2010 as Administrator, but it still doesn't work. When I look at the above folder path, all it has are PDBs. In my case, that is not the correct path. The correct path is: C:/Development/OpenSceneGraph-2.8.3/VS2010/bin/Release/ All of my DLLs, etc., are in that path. They are not in the folder that the cmake install step is looking in. I don't know how to get them to build into the path that the cmake install step is looking for them in (aside from manually editing each project file by hand). Does anyone have any advice? Thank you! Cheers, Frank[/quote] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31875#31875 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Postbuild error with ot11-OpenThreads??
Oh yes, that would explain it. I'll try using VS2008 when I get home (I just downloaded CMake yesterday so I think I have the latest version, but I'll double check that as well). -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31902#31902 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry Drawing Performance
Hi guys, The 700fps is just in wireframe mode with nothing else being drawn. Eventually I'll have to put it in a scene, and apply a special shader effect to it, which could reduce the frame rate. I don't know exactly what the frame rate will be, but I thought it might be fruitful (partially for curiosity's sake) to try some optimizations. rosme, thanks very much for your help. It appears that those features have been added since the 2.8.3 tag. Do you think I should update from the trunk to get the newest stuff? Or is there a better/safer procedure that I should follow? Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31649#31649 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Geometry Drawing Performance
Hello everybody, Can I trouble you with some questions about performance? My situation is basically this. I have a list of 54 drawables that I'm generating in-code. Not all of them are necessarily displayed on the screen at any given time, and in some cases, a certain drawables might be drawn more than once (accomplished by adding a second MatrixTransform parent above the associated Geode). In any case, I went for a naive implementation at first. Each drawable was an osg::Geometry object attached to an osg::Geode (which again, may have one or more osg::MatrixTransforms as parents). Each osg::Geometry had its own Vec3Array as a vertex array. The performance wasn't bad. It was around 700fps in wireframe mode on my machine. But I figured I could do better. So, I groups all of the verts for these 54 drawables into a single Vec3Array that all of the osg::Geometry objects shared. The primitive set (an osg::DrawArrays) would specify which subset of the vertex array to draw. I figured this would help because it would eliminate a lot of useless VBO bindings (or whatever else is going on under the hood). However, this actually cut the frame rate by about a third. This confused me, but in a way it made sense. My new master vertex array has well over a million verts! So maybe the memory requirements of this outweighs the savings I get from reducing VBO bindings? So anyway, I figured it might be a good idea to try to index this geometry, to cut down on the number of verts in the vertex array. Doing this, I was actually able to cut down the number of verts to just over two thousand. That's a savings of 99.84%! Of course, now I've got 54 separate primitive sets (I had to use osg::DrawElements, because it doesn't look like osg::DrawArrays supposed indexed geometry). But since these primitive sets are essentially vectors of USHORTs (rather than vectors of Vec3's), I'm still saving a significant amount of memory (about 725,00 bytes for the Vec3's and USHORTS versus about 16 million bytes for the huge Vec3Array). Yet, the frame rate remains at about 220fps, which is significantly lower than the naive method involving 54 separate Vec3Arrays totaling 1.4 million verts! I still have a ways to go. I'm thinking about seeing if I can use a triangle strip instead of GL_TRIANGLES, to save even more on memory used for verts. However, the logic for building the meshes with triangle strips will be much tougher, and will likely require smart use of degenerate triangles. I'm happy to do the work, but before I do, I just want to make sure that there isn't something that I'm missing. I tried setting the data variance of the osg::Geometry objects to Static, hoping that perhaps if I signal to OSG that I have no intention of changing those objects, it could put it in a more-efficient memory pool (perhaps). However, that didn't seem to affect the frame rate. Any advice at all would be greatly appreciated. Cheers, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31598#31598 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry Drawing Performance
Hello again, There is something else that I thought of. Here is a diagram of what one of these drawables might look like: http://imgur.com/lefTl.gif Because of the way that this drawable is generated (by recursively subdividing a quad), the indices are not necessarily in an order that is cache-friendly. For instance, the triangle in green is composed of indices 8, 12, 41. This may cause OpenGL to have to jump around the VBO in a random access fashion. Could this cause the lower frame rates when compared to my naive brute force method? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31599#31599 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry Drawing Performance
Another thing, Looking at the GL Trace output in glslDevil, it looks like my program is using vertex arrays. I can't tell for sure, but I think it is using vertex arrays because I don't see any calls to glBindBuffer and the pointer used in glVertexPointer looks like an actual pointer to data (035ce860) rather than an offset into a VBO. Is there any way to force OSG to use VBOs? I'm using 2.8.2. Thanks again, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31600#31600 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Red FPS indicator
Hello everyone, hope everyone is well. Sorry to bother you with such a simple question, but somehow I ended up with a red FPS indicator in the lower-left portion of my screen, and I have no idea how it got there! Does anyone know how to remove it? Thanks, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31481#31481 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Red FPS indicator
Haha, it turned out to be something that another programmer did, which I accidentally switched on through a bug in my code. Thanks, J-S, and sorry for confusing everybody. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31491#31491 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Drawing a subset of a vertex buffer...
Hello there, IIRC, OpenGL allows you to stuff several meshes into a single VBO, and then when it comes time to draw a mesh, you can specify an offset into this VBO along with the number of primitives to draw, in essence drawing only a subset of this VBO at a time. I was wondering if this same functionality is exposed in OpenSceneGraph? What I'd like to do is something like this: stuff the vertex positions into a single Vec3Array, and hand this array over to a single Geometry object. Then, instantiate one or more Geodes that each share this Geometry object, but each draws only a subset of the Geometry (each possibly drawing a different subset). Is this possible? Thank you! Cheers, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31431#31431 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Drawing a subset of a vertex buffer...
Thanks very much, Robert. Do you happen to know how I would specify the range of verts that an osg::Geometry object is responsible for drawing? Thanks again, Frank robertosfield wrote: Hi Frank, You can share a single osg::Vec3Array between multiple osg::Geometry, in the lastest OSG in svn/trunk and the 2.9.x dev series the buffer object support should also be flexible enough for you to manually specify the VBO for that particular Vec3Array. Robert. On Wed, Sep 8, 2010 at 7:01 PM, Frank Sullivan wrote: Hello there, IIRC, OpenGL allows you to stuff several meshes into a single VBO, and then when it comes time to draw a mesh, you can specify an offset into this VBO along with the number of primitives to draw, in essence drawing only a subset of this VBO at a time. I was wondering if this same functionality is exposed in OpenSceneGraph? What I'd like to do is something like this: stuff the vertex positions into a single Vec3Array, and hand this array over to a single Geometry object. Then, instantiate one or more Geodes that each share this Geometry object, but each draws only a subset of the Geometry (each possibly drawing a different subset). Is this possible? Thank you! Cheers, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31431#31431 ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31436#31436 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Drawing a subset of a vertex buffer...
Oh! That is fantastic, thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31438#31438 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Custom Drawing for Geode
That is some incredible information, thank you very much! =D -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31314#31314 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Custom Drawing for Geode
Hi, I am working on an ocean water effect that basically consists of a tessellated plane that undulates in a wave-like motion. It's just a flat plane, but it has a vertex shader that creates the wave motion by adding a few sine waves together. And this is working perfectly well, but my problem is that I want this ocean water surface to be about 2km^2, and I can't have that entire plane heavily-tessellated, or I'll run into trouble. =) So I need to make sure that only the parts of the water near the camera are heavily-tessellated, and that the parts of the water further away are less-heavily-tessellated. Pretty basic stuff for some of you pros, I'm sure. =) So what I've decided to do is divide the water surface up into a grid of cells, and give each cell a different tessellation level. A top-down view of it might look something like this: http://imgur.com/cVR5T.gif As you can see, the closer a grid cell is to the camera, the more heavily-tessellated it is. Also, note that if two cells of different tessellation levels are adjacent to one another, the cell with the lower-tessellation will have a special seam. Finally, the cells that are shaded in gray should not be drawn, because they are not in the viewing frustum. I don't want to totally re-compute the geometry for this each frame, so I've precomputed a set of 36 cell meshes, which covers 6 levels of tessellation, and 6 seam types for each level. Each of these pre-computed meshes is an osg::Geometry object. I've done this so that, each frame, all I have to do is decide which grid cells are in the frustum, and which of the precomputed meshes to draw at each visible grid cell location. I'm not quite sure how best to do this within the OSG paradigm, though. I thought about maybe creating an OceanGeode class that, during the cull traversal, wipes out its list of drawables, and then calculates how the grid should be laid-out, and then re-adds these Geometry objects back to its drawables list. However, I'm not sure if I can add the same Geometry object more than once, and even if I could, I'm not sure how I could instruct each drawable to draw in a different location, because if I recall correctly, drawables don't have their own transformation matrices. To solve the last problem, I could pass down a grid coordinate to the shader and have the vertex shader transform it to the correct place. That is a possibility. Alternately, I could assign each pre-computed Geometry object to a separate Geode, and then give each of these Geodes 0 or more MatrixTransform parents. Then, each of those MatrixTransforms would share a single WaterNode parent that manages them all. Or perhaps I should make my own WaterDrawable! But that would require knowing a great deal more about the whole rendering process in OSG than what I currently know (but I'm willing to read up on it if it is documented somewhere). Does anyone have any advice on this? Even if it's just to point me towards an example or tutorial, that would be a huge help. I checked the Instancing example, but in that example, the number of instances is decided at Geometry creation time, and the positions of each of the instances is determined from the InstanceID, which is not what I'm looking for. I looked at the Precipitation example, which seems to have a similar scheme involving drawing the same geometry over and over in different grid cells, but I found it a bit difficult to understand. And help would be greatly appreciated. Cheers, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31287#31287 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Choosing a different cull mask for Viewer's master camera seems to mess up shadows...
Hello friends, I am trying to improve the way that we utilize node masks. Right now, the cull mask for our Viewer's master camera is set to 0x (all bits on). So, a node will always be drawn if _any_ of its node mask bits are set. Right now, we're essentially using the node mask for three things: 1) To indicate whether the node should be drawn or is hidden 2) To indicate if the node should be a shadow caster 3) To indicate if the node should be a shadow receiver To this end, we have three basic masks that we bitwise OR together: visibleNodeMask 0x1 castsShadowsMask 0x2 receivesShadowsMask 0x4 So, a visible object that casts shadows, but does not receive them, would have a mask of 0x1 | 0x2 = 0x3. I'm sure you get the idea, as this seem pretty common. But the problem is, since our camera's cull mask is set to 0x, the visibility bit doesn't actually matter. If we want to hide an object, we have to set its node mask to zero. If we want to show an object that was previously hidden, we have to reconstruct its node mask, and that means we have to store its shadow state separately. This is all very silly, so I decided to try and set our camera's cull mask to 0x1. That way, the only bit that matters, as far as whether objects draw or not, is the visibility bit that we've already designated, and showing or hiding an object is a matter of simple, straightforward bitwise math. So I did this: Code: m_viewer-getCamera()-setCullMask(visibleNodeMask); And this seems to work fine, as far as determining which objects should be hidden and which objects should be shown, however now my shadows are messed up. I have a scene with one shadow caster, and the shadow appears as a full square below the caster. To me, it looks as though the camera that renders the shadow map is correctly identifying which object should be rendered, and adjusting its frustum to match the bounding box of this object. However, after the shadow map is rendered, the resulting shadow map is filled with depth values of zero (or nearly zero) -- almost as if it didn't actually render the caster into the shadow map. Just in case, I took a look at my scene graph in the debugger, just to see what the nodes' masks looked like. They all seemed to be what I expected. I know that you guys couldn't possibly tell me exactly what is causing my problem, because you have no idea what my code or scene graph looks like. However, I was hoping that perhaps this is a common-enough problem that has a well-known solution. Just a stab in the dark. I was reading elsewhere that, when setting the cull mask of the camera, one should also set the inheritance mask like so: Code: osg::Node::NodeMask inheritanceMask = m_viewer-getCamera()-getInheritanceMask(); inheritanceMask |= ~(osg::CullSettings::CULL_MASK); m_viewer-getCamera()-setInheritanceMask(inheritanceMask); I have no idea what this does. I tried it, but it didn't seem to help. Thanks, Frank[/code] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30939#30939 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Choosing a different cull mask for Viewer's master camera seems to mess up shadows...
Well, I got it to draw something other than a square shadow. =) Remember before I had said that the shadow appeared as a square-shape just below the shadow caster. It was about the right size and position for the caster, leading me to conclude that the shadow technique was correctly locating the shadow caster, and adjusting its view frustum to fit it prior to rendering the shadow map. Well, it's doing the same thing now, but now instead of this square 'shadow region' being filled with shadow, it's filled with a pattern of dots. The cool thing is that, among the dots, I do see a silhouette of the shadow caster! However, this silhouette appears to be offset by half the width of the shadow region. Thus, half of it is cut off, and wraps around to the other side! I don't know if you can picture that or not, but it's definitely very weird! But I have learned some interesting things from this! a) It's stable. That is, if I close the program down, and then start it back up again, I get the same exact pattern of dots with the 'offset and wrapped' silhouette. b) The shadow map isn't updating from frame-to-frame anymore. I've tried moving the directional light source's direction around, as well as moved rotated the shadow caster around. The shadow itself moves as expected, but it always looks the same. So, the position of the shadow changes, but the content of the shadow does not. It's like a projective texture with a static image of a weird shadow on it. I also tried this. Instead of setting the cull mask to 'visibleMask ', I set it to visibleMask | castShadowMask | receiveShadowMask. Now, the shadowing works perfectly! However, it still leaves me with my original problem, which is that if I want to hide an object, I can't just turn its visibility bit off, I have to turn the shadow bits off as well. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30944#30944 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Moving Particle Effects
Hello,
I am hoping to create a particle effect that moves. However, I am having
difficulty with this. If I call ParticleEffect::setPosition, it seems to have
the effect of destroying the existing particle system and rebuilding it from
scratch:
Code:
void ParticleEffect::setPosition(const osg::Vec3 position)
{
if (_position==position) return;
_position = position;
if (_automaticSetup) setUpEmitterAndProgram();
}
The result of this seems to be that only 1 particle is emitted before the
Effect is reset, causing perhaps 2-3 particles to be emitted per second rather
than the 200 or so that I set as the rate.
So, I tried to instead add this ParticleEffect as a child of a MatrixTransform
and, instead of moving the ParticleEffect with setPosition, I move the
MatrixTransform instead. This has an interesting effect. The emitter itself
seems to stay in the same exact spot. However, the particles have a definite
inertia to them. I tried moving the MatrixTransform in a continuous circle on
the x/y plane. The emitter didn't move, but the particles seemed to fly outward
from this position, as if they knew they should be flying out at the circle's
tangent, but weren't actually being emitted from changing positions on the
circle's perimeter.
Lastly, I tried setting the useLocalParticleSystem value to false, not knowing
what it was, but thinking it was worth a try. The result seems to be that no
particles are emitted (or perhaps they are emitted somewhere where I can't see
them).
Does anyone have any idea how I can achieve this, hopefully without modifying
OSG code?
Thank you!
Cheers,
Frank
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=30045#30045
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Moving Particle Effects
That works very well, Jordi, thanks. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30049#30049 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Sub-tree picking
Hi, I was wondering. I want to implement some picking, however I don't want to pick the entire scene graph. Just a sub-tree. I looked at osg::View::computeIntersections to try to replicate what it is doing. I have mimicked the code pretty much exactly, with one exception. Instead of having the camera accept the IntersectionVisitor, I have the root of my sub-tree accept it. However, it doesn't seem to be working. The LineSegmentIntersector has zero intersections. However, if I switch to having the camera accept the IntersectionVisitor, then I get all of the intersections I'm expecting (and many that I don't want). I tried a different approach: instead of having the sub-tree root accept the Visitor, have the camera accept it, since I know that works. However, give the root of my sub-tree a special nodemask so that the Visitor will affect it and ignore the others (the descendant nodes of this sub-tree root all have node masks of 0x so they will allow anything to traverse, but since the roots of the sub-trees that I'm interested in all have node masks of 0x1, this could work). The problem is, now I have to make sure that the _parents_ of these sub-tree roots all have this special bit set, which they don't, and managing that could be a pain. I could just feed the Visitor to the camera, compute all intersections, and then try to suss out which node sub-trees were hit. This is sort of what I was doing before, but I found it to be a problem because our scene graph structure is not set up in a way that I can just look at a certain element in the NodePath to know what I hit. I write a fair amount of intelligence into it, and actually this is the way I _have_ been doing it, and I'm trying to move away from it because it's becoming unwieldy. I already have a list of the sub-tree roots that I care about, and I'd much rather just be able to ask one of these roots Have you been picked? Does anyone have any suggestions? If so, that would be a huge help. Meanwhile, I keep plugging ahead and see what I find. Maybe the camera node is doing something to the IntersectionVisitor that I should know about? I'll take a look at that next. Thank you! Cheers, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29535#29535 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Sub-tree picking
Thanks very much, J-S. That explains everything. Luckily, your first solution will work for me because there aren't any other transforms in the way. However, the more-general solution looks more interesting so I think I will give it a try! =D Could be useful later, who knows. Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29538#29538 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] A challenge with diamond-shaped graphs...
Hello there, Let's say I want two cars in the scene. What I currently do is I load the car file once, but I give it two matrix transform parents, like so: http://imgur.com/kuSBu.gif This works well for me (the small graph stemming from the word 'car' is just there to emphasis that the car is actually a sub-tree of nodes and not a single object in of itself). The only problem is, what if I want these cars to move? As far as translating and rotating the cars, that's easy. I simply modify the matrix transforms, which I can do independently since they are separate objects. But I want to make the wheels look as though they are turning as well. I accomplish this with a simple texture matrix. I simply find the node that represents each wheel, and I add a texture matrix to each of them that will slide the s/t coordinates of the wheels' textures so as to give the illusion that the wheels are turning. This seems to work well also. Well enough for my purposes, anyway. The problem is when I have two cars in the scene, and the graph looks like it does above, I can't turn the wheels on one car without turning them on the other as well. Is the best solution to this to do a deep copy of the car's sub-graph rather than reusing the same sub-graph with two different matrix transforms? Thank you! Cheers, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27893#27893 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Sliding / Scrolling Textures
Hi, I am just trying to implement some sliding textures for things like waterfalls and what have you. I figure that the best way to do this is to modify the texture matrix. So, if I want to slide a texture in the U direction by 0.1 units, I would use a texture matrix that looks like this: Code: 1.0 0.0 0.0 0.1 0.0 1.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 0.0 1.0 Right? So I set out to do this, but it doesn't seem to work. I am wondering if anyone can help me make sure that I am doing this correctly? So the code I would use would look something like this, right? Code: // Create the texture matrix. osg::Matrix textureMatrix; textureMatrix.makeTranslate(0.1, 0.0, 0.0); // Create the Texture Matrix attribute osg::ref_ptrosg::TexMat textureMatrixAttribute = new osg::TexMat; textureMatrixAttribute-setMatrix(textureMatrix); // Set the Texture Matrix attribute osg::ref_ptrosg::StateSet stateSet = myNode-getOrCreateStateSet(); stateSet-setTextureAttribute(0, textureMatrixAttribute.get(), osg::StateAttribute::OVERRIDE); stateSet-setTextureMode(0, GL_TEXTURE_MATRIX, osg::StateAttribute::ON); Is that about it? I'm having trouble getting this to work. If I call this code each frame, with a new texture offset each time (first argument of the makeTranslate method call above), I do not get a scrolling texture. Instead, the texture doesn't move. Now, I know that this could be caused by a number of things, and that one could not possibly diagnose the problem for me without seeing the above code in the context of the entire system. However, I'm hoping that someone here will be able to spot something wrong about the above code, the solution to which might also be a solution to my problem. =) Thank you! Cheers, Frank[/code] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=26592#26592 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Sliding / Scrolling Textures
Skylark wrote: Hope this helps It sure did! Thanks! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=26594#26594 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Resizing a window
Hi, I was just wondering what is required when resizing a window. I've done this with Direct3D, and what it does is basically take your front buffer surface and then it stretch blits it to the client area of your window. If you want to avoid distortion when the aspect ration changes, you must, at a minimum, change your perspective matrix to reflect the new aspect ratio. Ideally, you would also change the dimensions of your front/back buffers to exactly match the size of your client area, but this was a bit more complicated as it required resetting the device (which, in turn, requires unloading and re-loading some of your resources, if applicable). Ok, so I haven't yet dealt with this issue in OpenGL. Would it require changing the rendering context, or possibly deleting it and creating a new one? I'm not sure, but I guess that is moot because I'm working with OSG and therefore those details are probably abstracted away to that extent. So I guess I'm just wondering how I could do this with OSG. In this case, I am not having OSG launch the window for me. Instead, I have a Panel control in an already-existing application that I'm using to display the rendered scene. To do this, I am passing the Panel's HWND to a WindowData object, and then assigning that object to the inheritedWindowData member of the Traits object that I use to create the graphics context. It works fine, but the image seems stretched horizontally, so I'd like to be able to fix that. Interestingly, I can't seem to 'fix' the stretching by resizing the Panel, which may be an indication that OSG, or something, is doing the aforementioned adjustments automatically, but in doing so, maintains the original aspect ratio, which as I said, results in a stretched image. Thank you! Cheers, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=23080#23080 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Linking difficulties with C++\CLI
Hi, I was wondering is anyone else has had experience with this problem. I have written a DLL of my own, which is written in C++, and makes heavy use of OSG. It is written so that any application that needs to display a scene can simply link to this DLL: OSG -- MyDLL -- App This works fine, as long as the App is native C++. The App simply links to myDLL, and the OSG stuff comes with it. However, when try to link to MyDLL from a C++\CLI App, I get a whole host of linker errors (unresolved external symbols), all referring to the OSG stuff. If I link my C++\CLI app directly to the OSG libraries, the errors go away. However, I am curious as to why it couldn't find the symbols in MyDLL. I thought that perhaps there was some C++\CLI quirk that prevented those symbols from 'carrying over'. To test this, I made two separate DLL projects, which I'll just call DLL_A and DLL_B, and tried linking them as follows: DLL_A -- DLL_B -- C++\CLI App And this works fine! So it appears to only be a problem with the OSG libraries, but I can't seem to figure out what that problem is. If I could, then maybe I could figure out how to build them differently. Note: I am not 100% sure that this is a difference between native and managed C++. All I can say for sure is that I've built several native C++ apps that link to MyDLL without any problems. This C++\CLI project that I'm having trouble with is the first, and only, managed project that I've tried. Thank you! Cheers, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21127#21127 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Would someone be willing to help me diagnose a performance issue?
Hello, I have two applications, both of which are displaying basically the same scene. One application runs at 230+ fps while the other runs at about 45 fps. I'm trying to figure out what is causing this performance difference. Using high-precision timers, I've been able to determine that the difference occurs somewhere in the rendering of the scene graph, but I'm not 100% sure where. I have a couple of ideas, but each will take some amount of time to investigate, and so I was hoping someone might be able to lead me towards the most-correct answer. The first idea I had concerns differences in how the scene graphs are structured in each application. The quick app works simply by loading the three models that it needs (from FLT files, so these 'models' are in fact complex sub-graphs) and attaches them to the root node, and sets that root node as the scene data. The slow app loads every model that could possibly ever be used (52 in all, and again each 'model' could actually be a complex sub-graph). These 52 nodes are then attached to the root, and their visibility is turned off by setting their node mask to 0. Then, if the user of the application wants to see a model, the app will copy the node (and all of it's children) and then add this copy to the scene root group, with the visibility turned on. This way, if the user of the app wants to populate the scene with many instances of the same model, they can do so, because each time they do it, a separate copy of the node is made. I realize that there are a lot of things that can be done to make the slow app more memory-efficient. For instance, it could use lazy loading to load a model only when it is needed (although this may cause a noticeable delay, but that would probably be fine). And if the user wants to see several instances of this model, this could be accomplished without copying the model's entire subgraph. Instead, we could simply create a new matrix transform, and add THAT to the root, and add the model's node as a child of this new matrix transform (at which point, the model's node will have more than one Matrix Transform parent). However, these issues seem to pertain more towards memory efficiency than rendering efficiency, so I'm not sure if this is going to solve my immediate problem (although it is almost certainly something I will implement later on). Related to this, I was wondering if anyone had an explanation as to what the Camera / View statistics referred to. I read the Quick Start Guide, and it had excellent information about the Event/Update/Cull/Draw/GPU chart at the top of the statistics screen, but I'm not exactly sure what the statistics in the Camera / View windows refer to. For instance, does the Vertices stat refer to the total number of vertices in all of the drawables, whether those drawables are visible or not? The reason I ask is that, in terms of these statistics, both the Quick App and the Slow App have nearly-identical numbers in the View section, but in the Camera section, the Slow App's numbers are way, way, way higher. I wonder if this tells me something about how to optimize the Slow App to bring it up to speed. The other major difference I noticed was in the threading model. The Quick App uses DrawThreadPerContext and the Slow App uses SingleThreaded. I tried getting the slow app to use DrawThreadPerContext by setting the environment variable, but it ignored that value and chose the SingleThreaded model for me. I can probably figure out why this happens, but I'm curious to know if you think this will affect performance much? Thanks so much to whomever has patience to read all this! Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19436#19436 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Would someone be willing to help me diagnose a performance issue?
Thanks for all of your help and suggestions, people. My plan for the last hour or so has been to first follow Philip's suggestion to see if I can get the Quick App to start behaving like the Slow App. My first step toward that goal was to replicate that 'object cache' by loading all 52 objects, adding them to the scene graph, each with their node masks zero'ed out. Then, for the three objects I actually want to display, I add them again separately. It turns out that this had little effect on frame rate. The Quick App is still quick. Although I still find Frederic's suggestion helpful and I plan on implementing it later, it doesn't look like it will affect the frame rate much, which is what I'm after at this point. So for my next step, I forced the Quick App to use the SingleThreaded model, which is the one that the Slow App uses. This actually seemed to give me a slight performance boost! Probably because, as Frederick mentioned, I only need a single thread for one display window (which is what I have) and so if anything, changing to SingleThreaded sped things up a bit, perhaps by getting rid of the overhead of managing multiple threads. So, the culprit is neither the 'object cache' nor the threading model. I will have to keep plugging ahead I guess. One difference I did notice, though, is that the numbers in the Camera stats window are still much, much higher in the Slow App than either versions of the Quick App. Slow App - Lights: 0 Bins: 30 Depth: 0 Matrices: 15,789 Imposters: 0 Drawables: 15,789 Vertices: 1,361,039 Quick App (without Object Cache) - Lights: 0 Bins: 9 Depth: 0 Matrices: 1,379 Imposters: 0 Drawables: 1,379 Vertices: 299,982 Quick App (with Object Cache) - Lights: 0 Bins: 9 Depth: 0 Matrices: 1,379 Imposters: 0 Drawables: 1379 Vertices: 300,530 I'm not sure exactly what these numbers mean. I thought that perhaps they referred to the total number of objects in the scene graph, whether visible or invisible, and whether or not they are in the viewing frustum. However, I noticed that the numbers change slightly depending on where I place the camera (therefore, I tried to place the camera in the same position for each of the data samples above to get the most comparable results). Also, if that were the case, then Quick App (with Object Cache) should have numbers comparable to Slow App -- they both have the exact same objects loaded and attached to the scene graph. However, both versions of the Quick App have similar numbers, while the Slow App numbers are way, way higher. If anyone can help explain what these stats actually refer to, I think I may be able to track this problem down. Thanks again, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19453#19453 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Would someone be willing to help me diagnose a performance issue?
Thanks, Bryan, I'll try and see if there's anything causing multiple re-draws of the geometry or something. Do you happen to know what the stats under the 'View' column refer to, in this case? E.g., StateSet, Group, Transform, Geode, Drawable, etc. These seem to refer more to higher-level osg concepts, except that this window, too, has a Vertices state which is slightly different than the one under the Camera column (in the Slow App's case, it's 231,648 Unique and 1,389,888 Instance). -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19455#19455 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Would someone be willing to help me diagnose a performance issue?
Thanks again, guys. Jean-Sebastien, I apologize, but I did not notice your reply until just now! I didn't write the Slow App code myself, but I do have the power to change it, if only on my local machine to test things. You are correct that, in both apps, the hierarchy is very flat, with a single group node, which I'll call the 'Scene Root', and all of the objects in the scene are children of this Scene Root, and siblings of one another. Although, by 'Object', what I really mean is a MatrixTransform that has, as its child, the root of a subgraph that contains many geodes, drawables, statesets, etc. It is the Matrix Transform that is given the 0x00 node mask in both the Quick App and in the Slow App. So, it SHOULD be enough to stop the cull visitor right away, and prevent it from looking any deeper into these objects' subgraphs. However, the way I did it in my Quick App is much simpler than how it is done in the Slow App. In the Quick App, for each object in the scene, I: - Load the FLT file assign the result to a Node* - Create a new Matrix Transform - Set the Node* as a child of the Matrix Transform - Set the Matrix Transform as a child of the Scene Root - Set the Matrix Transform's node mask to 0x00 However, in the Slow App, there's actually a Model class of our own making, that has an osg::Group* member that stores a reference to the model's parent node, and an osg::MatrixTransform* that stores a reference to the model's Matrix Transform. The constructor of this class follows the same basic steps I outlined above, in order to wire everything together, but it's possible that I'm overlooking something amongst the added complexity. Thanks again, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19459#19459 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Would someone be willing to help me diagnose a performance issue?
Hey guys, Just an update: it looks like someone turned off the side culling in the Slow App. This wasn't the case in my Quick App, so I guess that explains both the low frame rates and the comparatively high stats. The Slow App is still only running at 65 fps or so, but my profile data now indicates that the scene graph / rendering is no longer the bottleneck. So, I think that about wraps it up! Thanks to everyone for your help. Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19463#19463 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Rendering a depth texture quickly
Hello everyone, I've implemented a feature that is similar to shadow mapping in that I first have to render the scene from another point of view, and this rendering is depth-only. I'm not using it for shadows, but this first depth-only pass is conceptually the same. So right now, I have all the objects in the scene arranged in a subgraph, and this subgraph is attached to the viewer, as well as to a pre-render camera, which renders the depth texture. And one thing I'm wondering about is, it seems like this is inefficient, because during that first pass, I only need the depth. So, there's no need to actually set sample any textures, or do any other effects that these objects in the subgraph would normally use when rendering. Is it possible to perhaps override the normal rendering of the entire subgraph by, perhaps, setting the objects to use a simple set of shaders that does nothing but transform the vertices and render the depth? Could I do this using the camera node? Thanks, Frank Sullivan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18449#18449 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rendering a depth texture quickly
Hi Paul, Yes, that is what I meant, thank you. So, I guess the thing I'm wondering about is, if I add a shader to the camera's state set, how do I ensure that this shader isn't overridden by the child nodes? For instance, if there is a Geode in this subgraph with a conflicting state set (let's say it has a shader of its own), won't that state set override the camera's? Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18457#18457 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rendering a depth texture quickly
Thanks again, Paul. That looks like it will work nicely. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18463#18463 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cameras View Matrix - I am perplexed
I think that makes a lot of sense, Paul. After learning about this yesterday, it took me about a half hour to think it all through, and realize that it's all pretty much equivalent and boils down to arbitrary choices about how you want to orient your scene. Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18333#18333 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [forum] Cameras View Matrix - I am perplexed
Hello! I was wondering if someone could help explain the camera's view matrix to me. The reason I ask is that, when I look at it in the debugger, it is not at all what I expected it to be. Here's what I am doing. Before calling osg::Viewer::run(), I set the camera manipulator, and set its home position, like so: Code: viewer.setCameraManipulator(new osgGA::TrackballManipulator); viewer.getCameraManipulator()-setHomePosition(osg::Vec3d(0.0, 500.0, 30.0), osg::Vec3d(0.0, 480.0, 30.0), osg::Vec3d(0.0, 0.0, 1.0)); As you can probably tell, this should amount to placing the camera at 0,500,30 and then swinging it around 180 degrees on the Z axis, such that we're looking directly down the -Y axis. So if I wanted to create a world matrix for this camera, I would first create a 180 degree z-rotation matrix: -1 0 0 0 0 -1 0 0 0 0 1 0 0 0 0 1 And then I would multiply it against the translation matrix: 1 0 0 0 0 1 0 0 0 0 1 0 0 500 30 1 Which yields: -1 0 0 0 0 -1 0 0 0 0 1 0 0 500 30 1 So if there is a point that is [1,1,1] relative to the camera, multiplying it by this matrix would yield [-1,499,31], which looks to be the correct world-space position. On the other hand, if I wanted to know what the point [-1, 499, 31] is relative to the camera, I would need to know the inverse of the camera's world matrix, which is the view matrix, which happens to be what my question is about. So anyway, when I calculate the inverse of the camera's world matrix, I get: -1 0 0 0 0 -1 0 0 0 0 1 0 0 500 -30 1 Multiplying my world-space vector [-1, 499, 31] by this matrix yields [1, 1, 1], which is what I want. So, I'm satisfied that this is correct. The problem is, when I actually call osg::Camera::getViewMatrix() for this camera, what I get instead is: 1- 0 0 0 0 0 1 0 0 1 0 0 0 -30 -500 1 ..and multiplying [-1, 499, 31] by this yields [1, 1, -1], which is close, but not what I'm looking for (and I suspect it would be way off if I were multiplying with more interesting vectors). The thing is, the scene seems to render properly, and if I call osg::Matrix::getLookAt() on this (seemingly incorrect) view matrix, it gives me the correct values for the eye, center, and up vectors. So I was hoping someone could explain to me why this works the way that it does, perhaps by pointing out an error in my reasoning. I am trying to implement a shader that is similar to shadow mapping, and it's not working, and this is the only step along the way that isn't working as I expected it to. Thanks! Frank Sullivan[/code] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18302#18302 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cameras View Matrix - I am perplexed
Thanks Thomas, Yeah, I think you are right. I don't have it all worked out in my head how the coordinate system switch from osg and OpenGL occur. But I notice, now, that when I try to get getLookAt() on an identity matrix, I get: eye: 0, 0, 0 center: 0, 0, -1 up: 0, 1, 0 Instead of what I expected: eye: 0, 0, 0 center: 0, 1, 0 up: 0, 0, 1 i.e., the identity matrix still has me looking down the -z axis, just like OpenGL, even though in the osg World, I'm looking downwards. Thanks again, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18313#18313 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
