Re: [osg-users] 2.8.3 release: Last call for changes
Hi Paul, I think changeset 10520 http://www.openscenegraph.org/projects/osg/changeset/10520/OpenSceneGraph/trunk/ should be part of 2.8.x, as this fixes a memory leak with the object cache when not using the database pager. I added a workaround to all my 2.8-based apps, so the object cache gets cleaned after a while, as I am loading a lot of data dynamically and experienced out-of-memory-situations. cheers, Stephan Am 16.03.10 02:48, schrieb Paul Martz: Hi all -- I'm running slightly ahead of schedule on getting the 2.8 branch ready for the 2.8.3 release, so I thought I'd ping the list once more for change requests. If you know of any bug fixes for issues present in the 2.8.2 release, please cite the svn trunk revision number that fixed the bug, and I'll try to merge it onto the 2.8 branch. Likewise, I've found that backporting plugins is pretty trivial, so if there is a plugin that's been updated on trunk that you'd like to see in 2.8.3, let me know. I imagine DDS is a candidate, anyone else agree? Stephan Huber has tentatively volunteered to attempt to generate XCode files for the 2.8.3 release, but if there's anyone else willing to help out with this, please step forward. Barring further changes, I'll start to focus on generating the wrappers. Once that's done, and XCode files are updated, then we can go for a release candidate. Please test on the 2.8 branch and report any issues. Lots of info on the release can be found here: http://www.openscenegraph.org/projects/osg/wiki/Support/283release Thanks! -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in osg::Texture::computeInternalFormatWithImage / osg::Image
Hi Hartwig, On Mon, Mar 15, 2010 at 9:18 PM, Hartwig Wiesmann hartwig.wiesm...@wanadoo.nl wrote: OK, I can agree with this. But currently you do not get a feedback that you did something wrong. At least I would suggest that an error message is issued somewhere in the code if the internal format is set to a valid that is not OpenGL compliant. At the moment you get only the famous 'invalid enumerator' message from OpenGL after a while and you have no idea what went wrong. I used another library and it took me a couple of hours to track down the bug. I'm not sure what extra the OSG can provide. You can enable GL error testing per attribute by setting the env var OSG_GL_ERROR_CHECKING to ON, and this will give you a bit more feedback on which StateAttribute produced the error, but save from checking errors after every OpenGL call there really isn't too much more it can do without seriously impacting maintainability and performance. Perhaps better education on issues of using OpenGL/OSG and tracking down errors like this is required. This isn't just an OSG issue though, knowing OpenGL is a real asset. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] recommendation requested for using osg with dynamic geometry
Hi Chris, How you would tackle this depends greatly on what type of updates you will require. You don't really say what you are changing about the data and the motivation behind this so it's really hard to know what to recommend. Updates could range from changes to nodes to to vertices to uniforms. You say you want to update vertices but this may well not be the best route. Robert. On Tue, Mar 16, 2010 at 3:54 AM, Chris breath...@gmail.com wrote: Hi, I'd like some advice on using OSG for rendering many dynamic objects: I've got an app where as many as 10,000 objects (of 200 vertices each) may or may not be updated each frame. Perhaps about 10% of the objects would update on the average frame, but all of them could conceivably require it. I've been perusing the osg DrawElements code, with intention to use VBOs EBOs, and glBufferSubData to do the object updates. I'm trying to optimize this within the OSG framework. I'm thinking of having one Geometry node with 10K 'drawElements' primitive sets, each referencing the same (large) VBO and EBO. Alternately, maybe having several VBOs each containing a sub-group of the objects. I also notice a few blogs that recommend double buffering, i.e. releasing the VBO/EBO to GL while it draws frame A (via NULL pointer call glMapBuffer), and obtaining a pointer to a new or recycled buffer for filling in data for frame B. There's also a debate about using 'glMapBuffer' vs 'glBufferSubdata' to access the buffers. are ther any examples that employ double buffering in osg ? any other techniques/suggestions ? Chris C ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tell the DatabasePager to not touch that frame rate
I've been looking through the Culling for the PagedLOD, as far as I understand it, culling is only done for Drawables and therefore anything within distance to eye (regardless of frustum) get's loaded into memory/gpu which would explain A LOT as to why my system gets clogged. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25715#25715 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tell the DatabasePager to not touch that frame rate
HI Adrian, On Tue, Mar 16, 2010 at 11:13 AM, Adrian Lindberg osgfo...@tevs.eu wrote: I've been looking through the Culling for the PagedLOD, as far as I understand it, culling is only done for Drawables and therefore anything within distance to eye (regardless of frustum) get's loaded into memory/gpu which would explain A LOT as to why my system gets clogged. View frustum culling is done for all nodes, right from the top down to the drawable leaves. If a parent is culled then no traversal will be done on it's children. This feature is key to the performance of a scene graph. PagedLOD's are no different than other nodes - if it's bounding sphere is outside the view frustum it will be culled and never traversed. PagedLOD adds the lod based culling after view frustum culling operation is done, so is only done if the bounding sphere is within the view frustum. In your case I can't really say when the system is getting bogged down, but it's very likely to you having built a poorly balanced scene graph. As I don't know the specifics of your database I can't pinpoint what you have done wrong. The best I can do is point you in the direction of VirtualPlanetBuilder as it designed to build well conditioned scene graphs that work well when paging. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multi screen display issue
Hi, Actually I like to display a big video stream in original resolution, 3840 * 1 (width * height). The video will run contiguously upward covering the width resolution as it is. We don't want to configure Xinerama due to some other reasons. But when we run osgviewer to display some of the example models, it is automatically picking up both the monitors. I wud like to understand it. Thanks -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25717#25717 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ScreenShot File name
Hi Danny, however I beleive that this problem happens beause of line 545 in operator() filename _filename _ context_id; it will add context_id even if SetPolicy is set as OVERWRITE . I beleive this is bug. Isn't it? Ah, so the incrementing number was not indicating increasing numbers of images but increasing numbers of contexts. I can explain this, it is not a bug. In this case, the WriteFile class was designed to do something sensible in all cases. In the case where your View has multiple slave cameras with multiple graphics contexts, then one screen capture will need to capture multiple contexts therefore have multiple osg::Images to write to file. You wouldn't want them to be written to the same file. That's why we automatically add the context ID in all cases, to prevent this possibility. So the WriteFile class does something extra which you may not want, but it prevents errors in some cases. In your case that's not what you wanted, but as you saw it's pretty easy to override WriteFile to do what you want. It was expected that the default WriteFile would be used in the default osgViewer but users would make their own version. Now, I could have added controls in the WriteFile class to be able to make it do everything you might want, but I preferred to keep the class simple and make it easy for users to override it if they didn't like the behavior. Hope that explains it. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] FrameBufferObject and RenderStage
Hi, Some background: I've been fooling around with changing the format of render buffers and attachments on the fly, e.g. changing the number of multisamples. I can't make this work, either by changing the attachments of slave cameras or by stopping threading, deleting all the slave cameras, changing their attachments, and starting threading again. The result displayed on the screen seems to be coming from a frame buffer object that is not being used anymore. It does work to create cameras with the desired attachments and formats in advance and enable / disabled them with node masks, but I'd like to be able to cycle through all the supported color and depth formats, so that seems like a wasteful approach. Anyway, I'm willing to dive in and figure out what's going on, but first, a question. I notice that the frame buffer object (and resolve_fbo for multisampling) are stored with the RenderStage. So that means that there at least two FrameBufferObjects and their attachments allocated per camera that uses attachments. Is this a problem, or am I showing my ignorance of the situation? Do allocated frame buffer objects and attachments use up a lot of memory? It seems like we could make do with one fbo + one resolve fbo per camera. Thanks, Tim ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] how to load a model without its textures ?
Hello world, I would like to know if it's possible (and how) to load only geometry data from a 3d model file, without any texture ? I didn't found flags or options for doing so, and the ugly solution that unloads images loaders from the Registry is not an option for me, as I also load full models (with their textures). 3D model files may be of any 3D format, so modifying a reader plugin is not an option, the need is a generic one. thanks in advance for any idea ! Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] recommendation requested for using osg with dynamic geometry
Hi, Well, if your goal is like mine, I have a solution but it is not the best I don't know a better one as of right now: 1. set up a data struct that holds your objects and info to update the object of in the object list my list is very detailed as there are other things I track besides the position of an object and it's orientation: light on/off, fog on/off, label on/off, etc... 2. I also hold a copy of the object's PAX positionAttitudeTransform w/in my object list so that I may look it up quickly w/in OSG's node tree to update it when I need to. 3. Implement a locking mechanism to LOCK the OSG node tree each time you wish to update a node w/in the tree Why? Because I found that updating a node or PAX as I call it outside of the rendering loop causes a crash because while I'm accessing my PAX OSG's render loop can also access that very same node a crash occurs 4. When I insert or update a node into the node scene, I lock the OSG node tree, perform my insert/update, and then unlock the node tree. This is not the best way, but it is the only way I know of at this time that allows me to updated nodes in a real-time/semi-real-time simulation environment. However, constantly locking unlocking the node tree does slow the system down and I do believe that there is a better way. Cheers, Allen -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25721#25721 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help: how to rotate view camera 90 degrees in relationship to terrain
Aaaah, that explains some of what I'm seeing. Hum... Using the TerrianManipulator is different from the trackball manipulator but the idea is the same: setByMatrix I have been assuming to capture the entire state of the manipulator and to properly situate my camera exactly where I want and at the rotation I want. Guy, I am trying to rotate the camera 90 degrees with respect to a local coordinate frame. The local coordinate frame is actually @ the edge of the earth (a sphere or ellipsoid) so the camera must be orientated on the terrain at a 90 degree angle to it. Thank you both for your response. I appreciate the help! J.P. Delport wrote: Hi Allen, the problem with setMatrix is that it cannot fully encapsulate the state of the manipulator. Internally the manipulator (trackball) uses a distance, rotation and center, but all these variables do not fit into a matrix. The manipulator can calc a matrix from the internal variables, but not set them properly from an input matrix. E.g. the view might look OK, but the rotation point is somewhere weird. Some pointers to the past: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/8588/focus=8612 http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/19271/focus=19873 jp Allen Saucier wrote: Hi, thanks JP! :) I really appreciate your response. It appears I am fighting something I didn't expect and something I don't fully understand: the terrain manipulator. I understand what you've proposed but when I call the fucntion: setByMatrix() w/in the terrain manipulator, that function appears to be doing something to the matrix I send in that I am not expecting. What you've proposed is pretty much what I do except that I'm using quaternions and then converting those quats into matrices. So I can move the cam and I can even rotate it on the Z axis which is the position vector coming from the ECEF origin to the point on the terrain I'm working with and the cam is looking directly down that Z axis (local z-axis). It's just when I do a 90 degree rotation about the local x or y axis I get something totally screwed up and I don't know why but I think the mystery is w/in the terrain manipulator which I've not investigated more thoroughly as yet. I am hoping someone who has in depth knowledge about the terrain manipulator will see this post buzz me back on it. I have very limited understanding of the manipulator code w/in OSG as I'm still a novice w/ OSG so I get all mixed up when I delve into any of the manipulator classes: trackball, nodetracker and now terrain. thanks though! Thank you! Cheers, Allen -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25590#25590 ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ 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=25722#25722 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.3 release: Last call for changes
Paul, Were there any database pager fixes that could be backported to 2.8.3? I believe there were some serious bugs concerning the release of paged tiles. Thanks, Brett Paul Martz wrote: Hi all -- I'm running slightly ahead of schedule on getting the 2.8 branch ready for the 2.8.3 release, so I thought I'd ping the list once more for change requests. If you know of any bug fixes for issues present in the 2.8.2 release, please cite the svn trunk revision number that fixed the bug, and I'll try to merge it onto the 2.8 branch. Likewise, I've found that backporting plugins is pretty trivial, so if there is a plugin that's been updated on trunk that you'd like to see in 2.8.3, let me know. I imagine DDS is a candidate, anyone else agree? Stephan Huber has tentatively volunteered to attempt to generate XCode files for the 2.8.3 release, but if there's anyone else willing to help out with this, please step forward. Barring further changes, I'll start to focus on generating the wrappers. Once that's done, and XCode files are updated, then we can go for a release candidate. Please test on the 2.8 branch and report any issues. Lots of info on the release can be found here: http://www.openscenegraph.org/projects/osg/wiki/Support/283release Thanks! -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Brett Wiesner Product Manager, Visualize Products VT MAK www.mak.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.3 release: Last call for changes
Paul, One more... There are a feature added to PagedLOD that lets users specify options similar to the osgDB options. This lets users say something like use dds_flip for node under this PagedLOD which is useful if you have a paged terrain that has backwards dds textures. Thanks, Brett Paul Martz wrote: Hi all -- I'm running slightly ahead of schedule on getting the 2.8 branch ready for the 2.8.3 release, so I thought I'd ping the list once more for change requests. If you know of any bug fixes for issues present in the 2.8.2 release, please cite the svn trunk revision number that fixed the bug, and I'll try to merge it onto the 2.8 branch. Likewise, I've found that backporting plugins is pretty trivial, so if there is a plugin that's been updated on trunk that you'd like to see in 2.8.3, let me know. I imagine DDS is a candidate, anyone else agree? Stephan Huber has tentatively volunteered to attempt to generate XCode files for the 2.8.3 release, but if there's anyone else willing to help out with this, please step forward. Barring further changes, I'll start to focus on generating the wrappers. Once that's done, and XCode files are updated, then we can go for a release candidate. Please test on the 2.8 branch and report any issues. Lots of info on the release can be found here: http://www.openscenegraph.org/projects/osg/wiki/Support/283release Thanks! -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Brett Wiesner Product Manager, Visualize Products VT MAK www.mak.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help: how to rotate view camera 90 degrees in relationship to terrain
Hi Allen, I have a terrain manipulator I hope to release soon (which is ill-defined for where I work). For inspiration you can also look at the earth manipulator in osgEarth. jp Allen Saucier wrote: Aaaah, that explains some of what I'm seeing. Hum... Using the TerrianManipulator is different from the trackball manipulator but the idea is the same: setByMatrix I have been assuming to capture the entire state of the manipulator and to properly situate my camera exactly where I want and at the rotation I want. Guy, I am trying to rotate the camera 90 degrees with respect to a local coordinate frame. The local coordinate frame is actually @ the edge of the earth (a sphere or ellipsoid) so the camera must be orientated on the terrain at a 90 degree angle to it. Thank you both for your response. I appreciate the help! J.P. Delport wrote: Hi Allen, the problem with setMatrix is that it cannot fully encapsulate the state of the manipulator. Internally the manipulator (trackball) uses a distance, rotation and center, but all these variables do not fit into a matrix. The manipulator can calc a matrix from the internal variables, but not set them properly from an input matrix. E.g. the view might look OK, but the rotation point is somewhere weird. Some pointers to the past: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/8588/focus=8612 http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/19271/focus=19873 jp Allen Saucier wrote: Hi, thanks JP! :) I really appreciate your response. It appears I am fighting something I didn't expect and something I don't fully understand: the terrain manipulator. I understand what you've proposed but when I call the fucntion: setByMatrix() w/in the terrain manipulator, that function appears to be doing something to the matrix I send in that I am not expecting. What you've proposed is pretty much what I do except that I'm using quaternions and then converting those quats into matrices. So I can move the cam and I can even rotate it on the Z axis which is the position vector coming from the ECEF origin to the point on the terrain I'm working with and the cam is looking directly down that Z axis (local z-axis). It's just when I do a 90 degree rotation about the local x or y axis I get something totally screwed up and I don't know why but I think the mystery is w/in the terrain manipulator which I've not investigated more thoroughly as yet. I am hoping someone who has in depth knowledge about the terrain manipulator will see this post buzz me back on it. I have very limited understanding of the manipulator code w/in OSG as I'm still a novice w/ OSG so I get all mixed up when I delve into any of the manipulator classes: trackball, nodetracker and now terrain. thanks though! Thank you! Cheers, Allen -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25590#25590 ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ 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=25722#25722 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] bluring model edges
Hi, I am in need of this type of feature, too. I need to be able to take a model fuzz it's edges, though I must admit that I don't fully understand the code given, I'll try this. Thanks Guy for the ideas. Cheers, Allen -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25726#25726 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] recommendation requested for using osg with dynamicgeometry
Chris wrote: Hi, I'd like some advice on using OSG for rendering many dynamic objects: I've got an app where as many as 10,000 objects (of 200 vertices each) may or may not be updated each frame. Perhaps about 10% of the objects would update on the average frame, but all of them could conceivably require it. Are the objects all exactly the same (and you just need to move them)? If so, you could use instanced rendering (a la the osgdrawinstanced example). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] bluring model edges
Hi Julia, Allen, I have one solution that most probably seems to be wht you are looking for. I have been using OSG for doing some image processing. Thanks to Mr. Art Tevs' osgPPU. Render the scene to a texture T1, High pass filter this image using a shader to extract the edges (store to T2), followed by a Gaussian filtering of T2. Overlay this processed image over the original with a weight factor. Scene -- T1 -- [HighPass] -- T2 -- [Gaussian(LowPass)] -- T3-| | +-- T4 -- Output to Framebuffer || Regards Harash From: Allen Saucier allen.sauc...@itt.com To: osg-users@lists.openscenegraph.org Sent: Tue, March 16, 2010 8:27:51 PM Subject: Re: [osg-users] bluring model edges Hi, I am in need of this type of feature, too. I need to be able to take a model fuzz it's edges, though I must admit that I don't fully understand the code given, I'll try this. Thanks Guy for the ideas. Cheers, Allen -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25726#25726 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Bug in osg::Texture::computeInternalFormatWithImage / osg::Image
Hi Robert, enabling attribute checking does not help in this case because the state attribute setting itself is not causing the error. wxTexImageXX is going to fail and this function also reports the invalid enumerator error. As far as I can see there is nowhere code in OSG that allows somebody to track this error. I patched for myself osg::Texture::computeInternalFormatWithImage(const osg::Image) const. This seems to be a main method related to image to texture conversions. I am checking if the assigned internal format is valid and if not an error message is displayed. Cheers, Hartwig -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25732#25732 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] recommendation requested for using osg with dynamic geometry
Hey, Thanks for your replies.
Sorry about the fairly long post here , my earlier post I wanted to keep things
as generic as possible to avoid lengthy detail :)
My 10K objects of 200 vertices each are instances of a smaller set (say less
than 500) of 'prototype indexed meshes, each having 200 vertices as a
tri-strip. These prototype meshes don't change. Each instance has a different
world transform matrix. I indicated that about 10% or 1K of the objects would
change per frame, typically that would be changing their transform matrix but
could also change which static prototype mesh they refer to. I also have a
per vertex alpha array I need to apply to each instance vertex, and a small
number of other per-instance single valued parameters to be read by a vertex
shader.
There is a certain coherency in which objects change on a frame: if an object
changes on frame N it will change for a continuous period of time, e.g. until
frame N + 150 for (say) a 5 second anim at 30 fps. However any static object
may become dynamic at any time; it's arbitrary. I considered having a hash
table of VBOs, such that the likelihood of having to rebuild each static VBO
is diminished, but having even 10% of objects changing per frame means some
object they would likely hash to each VBO and thus most VBOs would require
rebuilding.
FWIW, I expect the GPU to be vertex-bound, as the actual pixel coverage of all
these objects combined is only about 30% of the display.
The obvious method (to me) is to render per instance, but...
a) I don't want to rely on hardware instancing), so have considered
pseudo-instancing using vertex attributes. I'd just draw each instance with its
own drawElements call. However, I thought this would duplicate the mem
transfers for the instances that did not change on the current frame (i.e. the
majority of instances) and also interrupt the GPU while setting new vertex
attributes for each instance. i.e. effectively:
Code:
for instance in Objects:
glVertexAttrib() // set attributes per instance
glDrawElements() // draws using either a single VBO or bank of VBOs
( could not figure out how to indent with bbcode, sorry :)
b) I also considered rendering the dynamic objects with pseudo-instancing, and
the static ones via one large baked instance VBO drawElements call, but
the problem is that any given object may switch from static to dynamic or
vice-versa on any frame, meaning that I'd have to rebuild the baked buffer per
frame anyway.
c) So I then considered just baking the 10% changed objects (world transform,
vertex alpha) on each frame, and updating them to the same big VBO with the
unchanged objects). A single glDrawElements call could then render the entire
set as a single concatenated tri-strip, provided I could somehow reject the
tris forming the sausage link between instances in the vertex shader. There
I'd need some kind of double buffering to avoid blocking while waiting for GL
to be done rendering with the VBO. That led to my question about how best to
update that single, big VBO.
d) Right now, I'm thinking a good way is to create one big static VBO ( IBO)
for all 10K instances, and one smaller VBO/IBO for the dynamic subset. I'd
render each instance with its own drawElements(), checking each to see if I
should override the static VBO and use the dynamic one. When an object switches
from dynamic to static, just keep rendering it as though dynamic. At periodic
intervals, rebuild the entire static VBO (every 3 seconds ?) to reflect the
dynamic VBO changes. At that time, all instances that change from dynamic to
static during that 3-second period would now be rendered as static again. As
pseudocode:
Code:
render()
{
bind_dynamic_VBO() // use VBO for 10% dynamic objects
for instance in Objects:
if dynamic (instance):
update_dynamic_VBO(instance);
for instance in list_of_dynamic( Objects ):
{
glVertexAttrib() // set attributes per instance, including embedded
world matrix for vertex shader
glDrawElements() // Draw. Note also using a static VBO/IBO to get the
prototype vertex xyz positions indices, (not shown)
}
// use VBO for static objects. Does rendering statics after dynamics help
ensure GL driver doesn't block access to the dynamic VBO on next frame ?
bind_static_VBO()
for instance in list_of_static( Objects ):
{
glVertexAttrib() // set attributes per instance, with baked world matrix
transforms
glDrawElements() // Draw, using same static VBO/IBO to get the
prototype vertex xyz positions indices, (not shown)
}
// periodic static buffer update...
if time_elapsed( 5.0 ):
bind_static_VBO() // updating VBO for static objects
for instance in Objects:
if dynamic_became_static(instance):
{
update_static_VBO( instance )
clear_dynamic_became_static( instance ):
Re: [osg-users] recommendation requested for using osg with dynamic geometry
Are the objects all exactly the same (and you just need to move them)? If so, you could use instanced rendering (a la the osgdrawinstanced example). Hi, They aren't all exactly the same,but each one is a copy of one in a palette of less than 500 protoype meshes. Yeah, I could just render per instance, but that would penalize the set of static instances that could be pre-transformed and rendered as a big non-instanced chunk. I can't precompute that set it because it changes gradually over time (as instances transition to static or dynamic and back again). See point (d) in my earlier reply for my current solution to this. Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25729#25729 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [build] windows 64bit ot11-openthreadsd.dll problem
Hi, I'm using osg v281. I downloaded the source and used CMake with the defaults and compiled it in 64bit with visual studio 9. I have success running the release version, but when I run in debug, I crash instantly, and the visual studio output window indicates that it is having a problem when loading ot11-openthreadsd.dll. I have used dependency walker to help me make sure that all dlls load correctly. When I use dependency walker the release version of ot11-openthreads.dll, everything passes without errors. When I use dependency walker on the debug ot11-openthreadsd.dll, I get an error message like: Error: The Side-by-Side configuration information for [path to ot11-openthreadsd.dll] contains errors. The application has failed to start because its side-by-side configuration is incorrect. I tried checking in the project settings in the visual studio project that cmake generated, nothing looks wrong to me there. Is anybody having similar problems with debug in 64 bit windows? Thank you! Cheers, Chad -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25730#25730 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] recommendation requested for using osg with dynamic geometry
On further thought, maybe the best (and simplest) thing is just to render per instance, transform with an instance's world matrix on the vertex shader, and stop trying to optimize the static stuff beyond storing the static mesh prototype vertex positions in a static VBO. I had thought baking the static objects into a single large interleaved VBO in VRAM and rendering with a single drawElements() would be fastest, but I wonder if it's worth the management hassle to update that VBO. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25733#25733 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] windows 64bit ot11-openthreadsd.dll problem
Usually it is not a good idea to attempt to run things from Debug mode... I think it might have something to do with your PATH variables... Wat about your manifest file? -Masoug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] recommendation requested for using osg with dynamicgeometry
Chris Chan wrote: Hi, They aren't all exactly the same,but each one is a copy of one in a palette of less than 500 protoype meshes. You mentioned that you don't want to rely on hardware instanced rendering. Does that mean you also don't want to rely on geometry shaders? Not sure if it's totally feasible, but your commend about prototype meshes made me think of using a geometry shader to look up vertices/indices from texture memory in a geometry shader and emit primitives from there. Input would just be the transform and the index of the prototype mesh. Just a thought. I haven't completely thought it through, so it might not work. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] recommendation requested for using osg with dynamicgeometry
Chris Chan wrote: Anyway, no matter what I choose, I'd still like to know if I should double buffer, either by glBufferData(0) or physically using two VBOs in a ping-pong scheme. I don't know the answer to that. If it were me, I'd try just single-buffered first, and then implement the double-buffer later if you find that you need it. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Texture Leak When Using Lots Of Different Texture Sizes
I have an app here that does the following:
while (1)
{
create a texture of a size we haven't used before
display it
wait a bit
delete it
}
Yes, essentially it's a fancy slide-show.
This eventually causes OpenGL to grind into texture-swapping hell.
DirectX's texture memory size calls confirm we're running out of GPU memory.
Plus debugging breakpoints show no calls to glDeletedTextures.
It seems that all my deleted textures are ending up stuck in the
pending-orphan-lists, but are never making it into the actual orphan lists,
where TextureObjectSet::flushDeletedTextureObjects() could clean them up.
It seems currently the only calls to handlePendingOrphandedTextureObjects
during normal operation are in the takeOrGenerate() call. But that's of no
help if you have lots of different texture sizes. All the pending
orphan lists for the other sizes are never processed.
So, can someone mod:
TextureObjectSet::flushDeletedTextureObjects() and
TextureObjectSet::flushAllDeletedTextureObjects()
to call handlePendingOrphandedTextureObjects() ?
seen in 2.9.6, SVN not tested, but looks no better.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] recommendation requested for using osg with dynamic geometry
Not sure if it's totally feasible, but your comment about prototype meshes made me think of using a geometry shader to look up vertices/indices from texture memory in a geometry shader and emit primitives from there. Yes, that's a good idea; but I didn't want to rely on geometry shaders either. I'm actually developing something that I want to have decent performance on a tablet PC, and my new Tablet's GL driver doesn't even have GS. Though I wonder if maybe hardware instancing is more ubiquitous these days than I think ? Thanks for your help :) Chris[/quote] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25738#25738 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Precipitation and VBO
On Mon, Mar 15, 2010 at 9:09 AM, Guy Volckaert guy.volcka...@meggitt.comwrote: As promised, I modified the osgprerender example to include a single instance of the precipitation effect and I was able to reproduce the problem. This sounds exactly like the problem I experienced a while back. Here is a link to the message from the archive: http://www.mail-archive.com/osg-us...@openscenegraph.net/msg06721.html -Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] windows 64bit ot11-openthreadsd.dll problem
Hi Masoug, Usually it is not a good idea to attempt to run things from Debug mode... That's SO not true. As long as you're running on a machine with the same version of Visual Studio installed, the debug binaries should run fine, and running in debug is the best way to (gasp) debug your applications... So I'm not sure what you meant by that statement. However, running a debug binary on a machine that does not have the same version of Visual Studio installed won't work in general (there are ways to get it to work, but it's pretty complicated). So, back to Chad's question, were you trying to run the debug binaries on the same machine as you compiled them, or some other machine without Visual Studio installed? The former should work, the latter not. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] windows 64bit ot11-openthreadsd.dll problem
Hi J-S, However, running a debug binary on a machine that does not have the same version of Visual Studio installed won't work in general (there are ways to get it to work, but it's pretty complicated). Sorry, I did not phrase that correctly. That was what I meant. I was in a ruch when I wrote that... :) -Masoug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to load a model without its textures ?
Hi Fred, A good idea is to just turn the file into a .osg and since .osg are text files, you can change them from there. -Masoug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to load a model without its textures ?
Hello Frederic, On 17/03/10 0:44 , Frederic Marmond wrote: I would like to know if it's possible (and how) to load only geometry data from a 3d model file, without any texture ? Two ideas: - run a visitor over the SG after loading and remove any Texture state or - use a ReadFileCallback that returns 'null' for all images, but I don't know for sure if this also removes the Texture objects or just doesn't associate an Image with them Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
