Re: [osg-users] PagedLod setCenter precision
oli tour wrote on 2013-01-27: I am just wondering how can I set the precision of the UserCenter member in a PagedLod. My problem is that I have coordinates higher than 1 million, and that the writer only keeps 5 decimals. I thus loses10 m precision, and this prevent the more detailled PagedLod to be loaded (or misplaced) when zoomming. when I do a osgconv file.osgb file.osgt, here is how my UserCenter PagedLod appears: Code: UserCenter 1.01925e+06 6.28286e+06 54.9003 21.7958 The center is however computed in double, so I exactly know the difference between the value displayed above and the right one. So, is there a way to specify an option when writing the node, to have a higher precision? It looks like the osgt serializer supports a precision option that should do what you want; simply pass an option string that specifies the precision you want, like so: osgconv -O precision 8 file.osgb file.osgt (note the option flag is capital o, not zero) Hope this helps! -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dynamic HeightField
bilal zeidan wrote on 2013-01-07: Hi, I tried to create a dynamic heightField by attaching a heightField Shape drawable into a Geode node, and then I called the dirtyDisplayList on each frame. I noticed that the frame rate drop a lot when the HF is quite big ( 200 x 200 ). I did the same test by using a drawable of type geom and I get a better perforamance. Display lists are best for drawables that do not change; if you are updating the height field every frame, you will probably get better performance by turning off display lists. Hope this helps, -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Integration of a NodeKit for Sky Rendering
Looks very nice, Daniel! I especially like the lunar eclipse effect. Limberger, Daniel wrote on 2013-01-18: I would like to present you my open source library osgHimmel that allows simple noninvasive rendering of background imagery (i.e., skies) within OSG. It currently is an OSG extending lib, that features two different techniques for sky rendering (or in traditional terms, skybox rendering): texture based (traditional) and computational (astrophysical). The first approach handles rendering of skies via common texture mapping techniques, extended by time based transitions, rotation around the zenith, horizon blending as well as an (experimental) faked sun. The second approach, renders astrophysical based skies with good results not only but especially at nightly scenes: correct star positions, atmosphere approximation, moon rendering including lunar eclipses and more. Further Contributions to OSG: - A useful, minimal astronomy library. - Good resources for both, texture based and physical based, approaches. - Solutions for common OSG issues, e.g., placing skies in arbitrary node structures, texture ping-ponging for post/pre processing, environment map rendering for reflection/illumination. - Starting point for cloud rendering. The current implementation is not very efficient though (TODO..) - Introduces no third parties, purely based on OSG (and optionally Qt for the editor)! For now, osgHimmel is mainly used internally at the Computer Graphics Systems group at the HPI (hpi3d.de), and the first integration into a commercial product is already in progress. We have two research projects, trying to extend the library by HDR, temporal-glare, Glare, simple as well as image based illumination. I would like to suggest an integration of osgHimmel into OSG, since a larger user base would convince me to keep osgHimmel alive and spent further development time on the library. What requirements must be met and what further steps have to be taken to make this integration possible (we can rename the lib to osgSky if this is a problem ;) )? Or is it better practice for such library to stay independent, without a direct OSG integration? I'm strongly interested in any ideas and concerns of this community concerning osgHimmel. All resources (including videos, demos, poster, my master's thesis, and a recent vmv2012 paper) are available at: http://osghimmel.googlecode.com recent poster with some images: https://osghimmel.googlecode.com/files/Daniel_Limberger_Poster.pdf https://osghimmel.googlecode.com/files/Daniel_Limberger_Poster.pdf Thanks a lot! And also thanks to this mailing list, which was of great help during development of osghimmel. -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Sharing culling results among multiple cameras
Frank Kane wrote on 2012-12-06: Let's say I have two cameras with identical view frusta, say a main camera and a camera for reflections that contain the same objects, only flipped. Except for in very specific situations, the objects in the reflection camera's frustum aren't going to be the same as the main camera's. Are you sure that this statement is true for your case? -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with perspective and depth value
Peterakos wrote on 2012-11-07: Hello. I use the following to render a cessna. Viewer viewer; viewer.setSceneData(group); Camera* camera = viewer.getCamera(); camera-setProjectionMatrixAsPerspective(45, 1, 1, 30); viewer.setUpViewInWindow(40,40,width,height); return viewer.run(); Question 1 According to perspective, it means that whatever is further than -30, is out of the view volume and will not be rendered, right ? I use the right click to make the cessna move away, but i still see it. What do i do wrong ? By default, OSG calculates the projection matrix for you; see osg::Camera::setComputeNearFarMode() and DO_NOT_COMPUTE_NEAR_FAR to use the projection matrix you are trying to set. Question 2 Is gl_FragCoord.z the right way to get the depth value of a fragment ? If the answer is yes, why is the cessna's tail white even though is so close to the screen ? What's the right way to get teh depth value ? Yes, that's the fragment depth value, but since OSG set the projection matrix and the tail is the farthest geometry, the far plane is immediately beyond it. Therefore, the depth value will be almost one. Also, the depth value is not linear from the near plane to the far plane, so depths very quickly get close to one as the geometry gets farther from the near plane. If you want to see how the depth changes better, you might want to linearize the values (there's lots of help on this on the Internet; for example, http://stackoverflow.com/questions/6652253/getting-the-true-z-value-from -the-depth-buffer). Hope this helps! -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Questions/proposal for readImageFile() - Detectunloaded images
Sukender wrote on 2012-10-31: Hi all, Here is a problem to solve : how can you highlight surfaces where textures didn't load properly (missing file, read error...)? My first answer was to create a ReadFileCallback, and make readImage() encapsulate default call. If call fails, then I return a dummy image (1x1 pixel, flashy color, such as magenta). However this doesn't work, as readers may call readImageFile() multiple times. Ex: image = readImageFile(path1); if (!image) readImageFile(path2); if (!image) etc... In my case, readImageFile(path1) returns either the normal image, or the dummy one (path2 is never tested). I propose to add some stuff to allow a ReadFileCallback to know a bit more about where the caller is. I'd like to know if you have any idea... Here are mine : 1. In all readers, call readImageFile() in the last case (or another method such as Registry::readImageFileFailed()), so that ReadFileCallback knows all other calls failed. Just ugly, I think. 2. In all readers, add something in the osgDB::Options structure in their last call, for the same purpose. Ugly too. 3. Change readImageFile() / ReadFileCallback to pass an additional parameter. Very ulgy! 4. In all readers, add a ValueObject (or something else) to record the fact loading failed. This would allow post-load code to detect this info. As you can see, I got no clean idea. Please help ! It seems better to just write your own visitor to traverse the scenegraph after loading to find the images that didn't load. Hope this helps, -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Memory Clean Up Question
Cary, Karl A. wrote on 2012-10-15: I am tracking down some memory leaks in our program and have come across a couple situations where I am currently not sure if it is/can cause a memory leak. There are many instances in our code where we do something similar: osg::ref_ptrosg::Geometry geo = new osg::Geometry; geo-getOrCreateStateSet()-addUniform(new osg::Uniform(blah, someVal)); geo-getOrCreateStateSet()-addUniform(new osg::Uniform(blah2, someVal2)); What I am wondering is, will osg now clean up those 2 new uniforms? Or do I need that be created externally as ref_ptrs so when my object deletes they will be deleted? I personally want to change it to ref_ptrs, but given the number of places this change needs to be made, I at least want to know if the work is truly needed or not. Hi Karl, Those uniforms are stored inside StateSet using ref_ptr (see the StateSet::RefUniformPair type), so they will be deleted when your geo is deleted, they will be removed too (as long as nothing else has a ref_ptr pointing to them). Hope this helps, -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How can I get the viewer's camera to 'ignore' a node's geometry?
Preet wrote on 2012-10-04: Sorry if it wasn't clear; the items aren't being displayed because the near and far planes that osg sets creates a frustum that doesn't include them. I need to manually set the near and far planes to see everything. The near and far planes that osg sets without the earth surface geometry is fine. Once you add the surface geometry though, the near and far planes are set such that the items are no long in the view frustum. If the surface geometry is in view but the calculated frustum doesn't contain it, then that sounds like a bug that should be investigated further. Are you certain the frustum really doesn't contain the surface geometry? It seems more likely that the problem is with z buffer precision due to the earth geometry pushing the far plane out so far that the surface geometry is getting buried, as other people in the thread have suggested. -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] getting RGB of texture in *.ive file
Joe Doob wrote on 2012-10-01: This snippet produces a valid drawable, however the drawable returns a NULL stateset and so I can't obtain the texture object. How can I obtain the osg::Image to get RGB in this case? Or, is there a better method? The texture for the Drawable must be set in a parent node (the Geode that contains it, or possibly some Node higher in the scene graph). You can use osg::Drawable::getParents() to work your way up the scene graph until you find the StateSet that sets the texture. Note that OSG combines StateSets, so even if you find a StateSet it might not specify the texture; it all depends on how the model is structured. Also, that part of the scene graph could occur multiple times in the scene graph if it is instanced (which is why getParents() returns a list: there could be more than one parent). Hope this helps, -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Invert scene graph
Stéphane Bonardi wrote on 2012-09-19: Since my overall setup is a bit complicated, I'm going to use here a simplified version to explain what I'm trying to achieve. Imagine that I try to create and animate a robotic arm with three degrees of freedom (articulations): I create a scene graph composed of a root node (osg::Group, called G, the basis of the arm) and three PositionAttitudeTransforms (P1,P2, and P3) corresponding to the articulations. The parenting relationship between those elements are the following: G is parent of (ipo) P1, P1 ipo P2 and P2 ipo P3. To each of those PositionAttitudeTransforms (PAT) I attached a node (osg::Node, called N1, N2, and N3 respectively) representing the physical model of the moving parts (loaded from stl files). So far everything is working perfectly and when moving the arm using a KeyboardEventHandler to move the different degrees of freedom the children of the articulations are moving accordingly. The particularity of the arm is that it can attached to the environment using its end effector (here N3) and detached its first articulation from the basis (N1 from G). I would like to be able to replicate such a behaviour meaning having alternatively G ipo P1 ipo P2 ipo P3 and G ipo P3 ipo P2 ipo P1. I would like to control the arm with the same events than before the disconnection: when I move P3, both P2 and P1 should be moving with the correct setting for the pivot points and positions. I already tried two options: - use the removeChild function to dynamically recreate the scene graph: the main problem is that it seems that the information regarding the PAT (both the position and the pivot point) are then incorrect. My guess was that those information are relative to the parent node but I didn't know how to correctly modify them afterwards. - having two different PAT for each node (like having a forward kinematic chain and a backward one): I did not think it was a good idea at the time so I quickly dropped the idea (I remembered obtaining two copies of each node displayed). My question would be the following: what would be the correct way to simulate such a behaviour, considering that there would be a succession of connection and disconnection (P1 and P3 being connected to the root alternatively)? Hi Stéphane, I think if you invert the matrices when you are doing backward kinematics, you can keep the same scenegraph structure. For example, when the end effector is attached, you have the transform from P3 to P2 but you have P2 ipo P2, so the inverse of the transform you have is what you should set the PAT transform to. Hope this helps, -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Understanding draggers - and a possible bug in OSG3.1 dev branch?
Christian Buchner wrote on 2012-09-13:
How would I use the object's own geometry of the object as the
clickable
hot spot?
I've been trying to implement a geode called DraggableCylinder which
inherits from the dragger. And I want this geode to also implement the
constrain() and receive() functions from osgManipulator::Constraint
and osgManipulator::DraggerCallback.
My class declaration (inheritance) now looks like this
class DraggableCylinder : public My2DDragger, private
osgManipulator::DraggerCallback, private osgManipulator::Constraint {
};
Now I ran into the problem that the DraggableCylinder inherits three
ref() functions from several osg::Object base classes. Is there any
way to resolve this ambiguity easily? ;-) Like providing one
definitive overload of ref()/unref() that calls into the ref()/unref()
functions of the inherited osg::Objects... I realize that this is more
of a C++ question, but maybe someone has solved this issue previously?
This is known as the diamond problem, and can be solved by virtual
inheritance (http://en.wikipedia.org/wiki/Virtual_inheritance):
class DraggableCylinder: public virtual My2DDragger, private virtual
osgManipulator::DraggerCallback, private virtual
osgManipulator::Constraint {};
Hope this helps!
--
Bryan Thrall
Principal Software Engineer
FlightSafety International
bryan.thr...@flightsafety.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDB::ReadWriter General Options Strings
Zach Basanese wrote on 2012-08-09: Hi, I can't seem to find this anywhere: What are the osgDB::ReadWriter general Options strings? I think I could potentially use them, but the only one I know of is keepExternalReferences. To set these options strings, the osgDB::ReadWriter::Options::setOptionString(string) method is used. Thank you! Hi Zach, Options strings are specific to the ReaderWriter that you are using, which depends on what format you're reading from or writing to. To see what options are available, use 'osgconv --formats'; it will print out all the plugins OSG knows about and their ReaderWriters, and will list the options available for each one under options. Hope this helps! -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] If anyone knows please explain about GL_LIGHT0
YoungStone, Jeong wrote on 2012-06-27: Hi, I'm studying OSG with Beginner's Guide Book. But I did not learn about OpenGL. snip In the code, GL_LIGHT0 and GL_LIGHT1 is being used. I know there are from GL_LIGHT0 to GL_LIGHT7. In my opinion GL_LIGHT0 features seems to be different from others. Who can you explain GL_LIGHT0 is this? I'm not sure what you're asking exactly but maybe this will help: In OpenGL, there is nothing special about GL_LIGHT0. However, osgViewer::Viewer by default uses GL_LIGHT0 as a headlight. You can change this behavior by setting the OSG_DEFAULT_LIGHTING environment variable (see 'osgviewer --help-env') or by calling setLightingMode() on your osgViewer::Viewer. Hope this helps! -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Author permissions on openscenegraph.com
I'd like to help migrate the OpenSceneGraph.org website over to the new OpenSceneGraph.com, but I'm having a bit of trouble: I have a login at OpenSceneGraph.com but I think I don't have author permissions because I don't see a button or link anywhere allowing me to submit new pages or edit existing ones. The Migration Tasks and Author Guidelines pages mention contacting the website admins about getting author permissions, but I don't see anywhere that actually lists who those people are or how to contact them. Now, from the mailing list, I know Jordi Torres is the person to talk to :) So, I have two questions: Jordi, would you give me the permissions I need to help with the migration? Can we add a page to OpenSceneGraph.com describing who the website admins are and how to contact them? Thanks, -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Author permissions on openscenegraph.com
Robert Osfield wrote on 2012-06-27: I have just updated your permissions to publisher, editor and author so you'll be able to write a page and then publish it directly without requiring publishes to review your work. Thanks! On 27 June 2012 18:01, Thrall, Bryan bryan.thr...@flightsafety.com wrote: I'd like to help migrate the OpenSceneGraph.org website over to the new OpenSceneGraph.com, but I'm having a bit of trouble: I have a login at OpenSceneGraph.com but I think I don't have author permissions because I don't see a button or link anywhere allowing me to submit new pages or edit existing ones. The Migration Tasks and Author Guidelines pages mention contacting the website admins about getting author permissions, but I don't see anywhere that actually lists who those people are or how to contact them. Now, from the mailing list, I know Jordi Torres is the person to talk to :) So, I have two questions: Jordi, would you give me the permissions I need to help with the migration? Can we add a page to OpenSceneGraph.com describing who the website admins are and how to contact them? -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Ideas about a resource system, and deferred rendering framework
Wang Rui wrote on 2012-06-21: 2. A rendering framework uses one or more techniques, passes, and connect their inputs/outputs for complex render work. It can also be recorded by the resource system and is implemented as a group node in the scene graph, which performs actual forward/deferred rendering work. It seems like osgPPU already does this; you might want to look at it to see if it meets your needs, or at least could inspire what you're doing. Hope this helps! -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ProxyNodes
PCJohn wrote on 2012-05-09: Hi, I want to load my scene from multiple files. There should be one main.osgt file that should include or reference other files. I was expecting that osg::ProxyNode should serve for this purpose. Or is there another friendly approach? ProxyNode difficultly: - it does not support immediate loading of referenced files, e.g. ProxyNode is loaded on the next cull traversal only. Not immediately. As a result, I can not make pure geometry processing (without scene visualization) as all geometries of ProxyNodes just remains on disk. Or, is there an convenient approach to force ProxyNodes to be loaded? The best approach for me would be to indicate in osgDB::readNode() call that I want to read specified file including all ProxyNodes within it. Probably the easiest thing to do would be to create a DatabaseRequestHandler subclass that loads the file immediately and attach it to a NodeVisitor that you have traverse your model as soon as it is loaded. Hope this helps, -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Building new website, assistance appreciated!
Paul Martz wrote on 2012-04-11: Has anyone successfully registered an account yet? I went through the registration process and was informed I would be sent an email with an activation link. That was about 1/2 hour ago; still no email... I just successfully created an account, activated it, and logged in. Check your spam filter? -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Case IN-sensitivity for osgDB when searching for files
Chris Hanson wrote on 2012-02-03: Ran into a problem where models made on a Windows box didn't work on a Linux box because the modeler had stored texture filenames in the file in one case foo.jpg and the actual image file was a different case foo.JPG. ... Is there a better way to do this or away to do this already? Is there an osgDB callback that I could hook into that would let me make one last-ditch effort at finding a file before osgDB gives up? You could add a osgDB::ReadFileCallback to the osgDB::Registry that would do a case-insensitive search for the file. -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] FOV
Shaheed Khan wrote on 2012-01-19: Hi, I am new to OSG ... Hi Shaheed, and welcome! The best place to send your questions is the osg-users list instead of the osg-submissions list (which is for code change submissions). I've forwarded your email to osg-users and copied you on it in case you aren't subscribed to that list. Good luck with your question, I'm sorry I don't know the answer! I want to control my camera horizon and vertical movement in Flightgear using Osg functions .. i tried using setCameraParameters (float vfov, float aspectRatio) but couldn't :( ... i am sing OSG 2.8.0 and FG 1.9.0 any suggestion plz .. Thank you! Cheers, shaheed -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Converter OSG - ?
Nicolas Baudrey wrote on 2012-01-12: Hi, I have a scene file in OSG format. I would like to convert it in a more convenient format in order to modify it in an modeling tools like 3DSMax, Maya, ... Is there a converter from OSG to 3DS or something like that ? The OSG tool osgconv can be used to convert OSG files to other formats; see the output of 'osgconv --formats' to see what ones are supported. Hope this helps, -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparency Bin Default Behavior
Jason Daly wrote on 2011-11-08: On 11/08/2011 04:51 PM, Buckley, Bob CTR MDA/DES wrote: I got the per state solution. But, I'm looking for fixing the transparency bin. Should be on that bin rather than wasting resources on identifying and setting on all the applicable states - transparent colors and textures. Hmm. You can set a StateSet on a RenderBin, but I'm not entirely sure if that would accomplish your goal or not. It's also a bit of a pain to get to the RenderBin objects from the Viewer, but I think it's possible: viewer.getRenderer().getSceneView(0).getRenderStage().getRenderBinList( ). find(osg::StateSet::TRANSPARENT_BIN); The Renderer has two SceneViews for double-buffering, so you'd have to do this on both. Hopefully someone will correct me if this is totally wrong :-) I haven't tested this, but you can try modifying the StateSet on the prototype that the transparent bin is created from: RenderBin::getRenderBinPrototype(DepthSortedBin)-getStateSet()-... That assumes all DepthSortedBins should have depth writes disabled, though. Hope this helps, -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RTT multipass on same geometry
Sebastian Messerschmidt wrote on 2011-09-21: Thank you Paul, It seems a little bit more obvious now. Basically I need to write some additional value to one of the COLOR attachments alpha channel, which is derived from the first pass. So my second approach (which seems to be failing) is somehow to write only to those texels in my color attachment of the second pass, where depth != far. Right now I really feel stupid, as I thought that there must be any easy way to do so. Any ideas how to render extra properties to the color buffer attachment at the positions that have been written in the first pass without re-rendering the whole scene? You could write to the stencil buffer in the first pass, then render a full-screen quad with the stencil test enabled on the second pass to only write to the pixels written to in the first pass. osgPPU might be useful to you for doing this. On 9/21/2011 10:54 AM, Sebastian Messerschmidt wrote: Hello, I've have a question regarding RenderToTexture in a multipass setup. I have to RTT cameras, the first one has DEPTH and 3 color attachments, while the second has only one color attachment. I need to use the data from the first RTT-pass in the second camera, so the renderorder is set accordingly. Basically my scene is organized like this: root | RTTCamera_1 ||Model RTTCamera_2 ||Model Booth cameras use the same geometry, viewport, transform. Yet the Model graph is culled twice. Is there any way to prevent the second cull traversal? I.e. reuse the batch collected in the first culling? In OSG, culling (the CullVisitor) also collects state. Since you are almost certainly using two different shaders (one that writes to three targets, another which writes to one), it's unlikely that OSG's state graph can be reused in your situation. -Paul -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Skipping nodes in serialization
Robert Osfield wrote on 2011-09-05: There isn't a scheme for missing nodes during serialization. On Sat, Sep 3, 2011 at 12:01 PM, Joel Graff pair_o_gra...@comcast.net wrote: Hi, I have a graph that I serialize with a simple call to osgDB::writeNodeFile(), but it contains a node that is auto-generated when the application starts. Is there a way to exclude that node from serialization? I'm familiar with the setNodeMask() / setTraversalMask() mechanism used in visitor classes, but wasn't finding something similiar for serialization - nothing jumped out at me in the ReaderWriter docs, anyway. Joel, You could try writing a WriteFileCallback and adding it to the osgDB::Registry which modifies the node mask, serializes the nodes, then restores the mask. This would cause problems if you were using the nodes elsewhere at the same time, though (such as for rendering). -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Add ancillary data file to an archive
Eduardo Poyart wrote on 2011-03-28: But I can't add an osg::Object to an osg::Group... I want my data to be saved with the scene, so I made it derive from osg::Node and added it to my root group. Unless there is another way? You can add it as user data (see osg::Object::setUserData()) if it is an osg::Object. It looks like user data is serialized. On Mon, Mar 28, 2011 at 11:00 AM, Robert Osfield robert.osfi...@gmail.com wrote: On Mon, Mar 28, 2011 at 6:52 PM, Eduardo Poyart poy...@gmail.com wrote: I did it with the serializers. The document on the Wiki helped a lot. I would be lost without it. The only funny thing is that I had to make my class derive from Node and add it to the scene graph, even though it's not graphics related at all! I don't know the specifics of your case, but serializers work for any object subclassed from osg::Object so there isn't any need to subclass from osg::Node. So if you hadsome custom user data you could subclass from osg::Object and then provide the serializers for this subclass and in theory the serilizers should then output your object. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] light multi-parenting
PCJohn wrote on 2010-03-19: 2. LightSource question: I was always wondering why there are two light classes - osg::Light and osg::LightSource - and not just one. Is the only purpose for having both osg::Light and osg::LightSource the ability of LightSource to specify ReferenceFrame? Apparently, osg::Light as Attribute can not have reference frame. Any other reasons, or am I missing something? osg::Light is a StateAttribute and osg::LightSource is a Group, so Light represents the OpenGL state (like the light ID) for a light in the scene, and LightSource represents the location of that light (note that LightSource has a Light). HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] light multi-parenting
PCJohn wrote on 2010-03-19: Hi Bryan, osg::Light is a StateAttribute and osg::LightSource is a Group, so Light represents the OpenGL state (like the light ID) for a light in the scene, and LightSource represents the location of that light (note that LightSource has a Light). And why there is LightSource? What is meaning of it? I think, I can live just with osg::Light. And really, I used only osg::Light in my application. Is there any reason for me or anyone else to use osg::LightSource? You place the LightSource in the scene graph where you want the light to be positioned. I don't think it is necessary for directional lights (they are infinitely far away, so don't have a position), but say you want a spotlight attached to a train locomotive. You could update osg::Light's position every time the locomotive moves, or you could attach a LightSource to the locomotive's scene graph and have the light placed correctly automatically. HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multi-view Performance Issue with Statesets
Drolet, Frederic wrote on 2010-03-12: osg::ref_ptrosg::StateSet lStateSet = mGeometrie- getOrCreateStateSet(); lStateSet-setMode(GL_LIGHTING, osg::StateAttribute::OFF); OpenGL performance is very sensitive to state changes, so it is a good idea to minimize them as much as possible. OSG groups Drawables with the same state as part of this (the exception is transparent drawables that require a certain ordering to render correctly, so they can't be grouped), but it just compares the StateSet pointers rather than a (much more expensive) comparison of what OpenGL state the StateSet pointers represent. Therefore, if you have a bunch of StateSets that are identical, like you seem to have, it is a really good idea to just use the same StateSet object everywhere you need it, rather than create a new instance every time. HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multi-view Performance Issue with Statesets
Drolet, Frederic wrote on 2010-03-12: Let's say I want to change the color of my road segment (when selected for instance). We're currently doing this modification that way: osg::Vec4Array* lCouleur = (osg::Vec4Array*)(mGeometrie- getColorArray()); *(lCouleur-begin()) = pCouleur;mGeometrie-dirtyDisplayList(); From what you're saying, I guess we should create a different stateset for every color instead of a stateset for every segment? Maybe I should ask first if the color is indeed part of the stateset anyway! If not, we could reduce the stateset count even more! The color array is independent from the StateSet. It appears you are only using the StateSet to turn lighting off; if that is true, you could just create a single StateSet that turns lighting off and put it near the top of your scene graph. The color arrays and modifying them should not affect performance as much as the OpenGL state changes that come from many StateSets. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- boun...@lists.openscenegraph.org] On Behalf Of Thrall, Bryan Sent: Friday, March 12, 2010 10:39 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Multi-view Performance Issue with Statesets Drolet, Frederic wrote on 2010-03-12: osg::ref_ptrosg::StateSet lStateSet = mGeometrie- getOrCreateStateSet(); lStateSet-setMode(GL_LIGHTING, osg::StateAttribute::OFF); OpenGL performance is very sensitive to state changes, so it is a good idea to minimize them as much as possible. OSG groups Drawables with the same state as part of this (the exception is transparent drawables that require a certain ordering to render correctly, so they can't be grouped), but it just compares the StateSet pointers rather than a (much more expensive) comparison of what OpenGL state the StateSet pointers represent. Therefore, if you have a bunch of StateSets that are identical, like you seem to have, it is a really good idea to just use the same StateSet object everywhere you need it, rather than create a new instance every time. HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn trunk build broke
Mourad Boufarguine wrote on 2010-02-22: Just a small typo correction for the last link in http://www.openscenegraph.org/projects/osg/wiki/Community/Maintainers, I think you meant http://cdash.openscenegraph.org http://cash.openscenegraph.org/ and not http://cash.openscenegraph.org http://cash.openscenegraph.org/ :) Fixed! -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Image-setData(unsigned char* data,AllocationModeallocationMode);
Roman Grigoriev wrote on 2010-02-01: Transmittance_t-setImage(image_Transmittance); delete[] data; setImage() uses the data buffer you pass to it, so if you delete it right after calling setImage(), the Image will use a deallocated buffer! Does it work if you specify USE_NEW_DELETE (so the Image will delete the buffer for you when it doesn't need it any more) and don't delete[] data? -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::StateAttribute::PROTECTED meanings
Trajce Nikolov wrote on 2010-01-20: is this meaning the attribute can not be overwritten from the top of the hierarchy? is so, does not work for me Yes, that is the meaning. However, the top of the hierarchy can use OVERRIDE to override the PROTECTED state, IIRC. Can you give an example of how you trying to use PROTECTED? Perhaps something else is going wrong... -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Node::Description intoageneralized propertymechanism?
Ulrich Hertlein wrote on 2009-12-31:
I have coded up a proposal for a general-purpose property system for
osg::Object and would
like to present it for comments and discussion.
Looks very cool!
For data that is not derived from osg::Referenced (like floats, int,
strings) instead of
using a variant class I've created the following template class:
template typename T class Property : public Referenced {
public:
//...
void set(const T data) { _data = data; }
const T get() const { return _data; }
T get() { return _data; }
private:
T _data;
};
Data is stored like this:
osg::Propertyint* ip = new osg::Propertyint(42);
obj-setProperty(my.int, ip);
and retrieved like this:
osg::Propertyint* ip0 = dynamic_castosg::Propertyint (obj-
getProperty(my.int));
ip0-get() == 42;
The assignment and comparison syntax is a little odd; I think adding
operator=(), operator==(), etc. to osg::Property would be better, so you could
do
*obj-getPropertyint(my.int) = 42;
if (*obj-getPropertyint(my.int) == 42) { ...}
Thanks for the hard work, I'm looking forward to seeing this in OSG :)
--
Bryan Thrall
FlightSafety International
bryan.thr...@flightsafety.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPPU] CMake error in FindOSG.cmake
The last two paths in OSG_SEARCH_PATHS in osgPPU's FindOSG.cmake don't properly escape backslashes, causing CMake (I'm using version 2.6) to error when trying to configure on Windows and osgPPU is not right next to OSG: C:\Program Files\OpenSceneGraph C:\Program Files (x86)\OpenSceneGraph Should be: C:\\Program Files\\OpenSceneGraph C:\\Program Files (x86)\\OpenSceneGraph Fixed FindOSG.cmake is attached. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com FindOSG.cmake Description: FindOSG.cmake ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPPU] CMake error in FindOSG.cmake
Paul Martz wrote on 2010-01-04: That was my mistake, found it after I posted the addition of these paths, but forgot to contact Art about it. Forward slashes also work. (Not sure why CMake is treating these as literal char strings... Seems like a bug in how CMake is parsing the file...) Apparently, CMake allows escaping inside strings using backslash (see http://www.cmake.org/cmake/help/syntax.html), hence the need to escape the backslashes. Thrall, Bryan wrote: The last two paths in OSG_SEARCH_PATHS in osgPPU's FindOSG.cmake don't properly escape backslashes, causing CMake (I'm using version 2.6) to error when trying to configure on Windows and osgPPU is not right next to OSG: C:\Program Files\OpenSceneGraph C:\Program Files (x86)\OpenSceneGraph Should be: C:\\Program Files\\OpenSceneGraph C:\\Program Files (x86)\\OpenSceneGraph Fixed FindOSG.cmake is attached. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] theading mode question
Pecoraro, Alexander N wrote on 2009-12-17: Is there a way to set the threading mode so that the draw thread does not run until after the update traversal is done? You can set the threading mode using an environment variable: $ osgviewer --help-env Usage: E:\OpenSceneGraph\bin\osgviewer.exe [options] filename ... Environmental Variables: ... OSG_THREADING valueSet the threading model using by Viewer, value can be SingleThreaded, CullDrawThreadPerContext, DrawThreadPerContext or CullThreadPerCameraDrawT- hreadPerContext. ... You can also do it programmatically via osgViewer::Viewer::setThreadingModel(). But I'm not sure that will help you; IIRC, only the cull and draw traversals can overlap, the update traversal should finish before either of those starts. What is the problem you're trying to solve, perhaps there's a different way to fix it? HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] file extension alias
Paul Martz wrote on 2009-12-14: Thrall, Bryan wrote: When you add an alias, though, aren't you saying to the plugin, Trust me, even though you don't recognize the file extension, handle it? Hi Bryan -- That might be what you're saying, but that's not how osgDB::Registry is interpreting it. :-) Yep, I was proposing that users of the Registry could interpret adding an alias differently than is currently implemented (exactly as Jan did). But it sounds like Robert isn't open to changing the meaning like that, so people who want to add unsupported extensions will have to write their own pseudoloaders. At least in the future, people who are confused about aliases will have this conversation to refer to! -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] file extension alias
Robert Osfield wrote on 2009-12-15: FYI, if you really want to try forcing a plugin to handle extensions it was never designed to handle you could try loading the plugin and then calling supportsExtension on it. Just to be pedantic, supportsExtension() is protected, so you'd need to: 1) create a subclass of the plugin's ReaderWriter (which would pull in the plugin DLL, registering the plugin with the Registry) that calls supportsExtension() 2) Remove the plugin's ReaderWriter from the Registry 3) Register your subclass with the Registry I'd guess that's about as much work as writing a pseudoloader :) -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] file extension alias
Paul Martz wrote on 2009-12-15: I think we've all been saying supportsExtension when we meant to say axxeptsExtension (which is public). I know I always get them confused. acceptsExtension() checks if the plugin handles that extension; if you want to add an extension so the plugin handles it, you need to call supportsExtension(). Thrall, Bryan wrote: Robert Osfield wrote on 2009-12-15: FYI, if you really want to try forcing a plugin to handle extensions it was never designed to handle you could try loading the plugin and then calling supportsExtension on it. Just to be pedantic, supportsExtension() is protected, so you'd need to: 1) create a subclass of the plugin's ReaderWriter (which would pull in the plugin DLL, registering the plugin with the Registry) that calls supportsExtension() 2) Remove the plugin's ReaderWriter from the Registry 3) Register your subclass with the Registry I'd guess that's about as much work as writing a pseudoloader :) -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] file extension alias
Paul Martz wrote on 2009-12-14: Jan Pečiva wrote: OSG plugin takes one look at the foo extension and returns an error. (This is correct behavior; the .osg plugin doesn't support the foo extension.) This is exactly the point I am trying to point out! The plugin reports that it does not support the extension! Oh, I thought you were saying that the alias doesn't get registered if you set it from your app. I am telling that this is NOT a good idea. And finally, the discussion about design ideas can start. I think it's a very good idea for a plugin to quickly reject a file if the extension name is wrong. This is a matter of efficiency. The plugin shouldn't waste time trying to read a file that it knows it doesn't support. To support your usage, you should write a pseudoloader: a plugin that accepts extension ivx (or whatever) but then turns around and invokes the actual plugin to load the file. See osgdb_scale, osgdb_trans, etc. When you add an alias, though, aren't you saying to the plugin, Trust me, even though you don't recognize the file extension, handle it? It would make sense, IMHO, for osgDB::Registry to add aliases to each plugin's list of handled extensions, and I don't think that would take too much work to do (make ReaderWriter::supportsExtension() public and call it in getReaderWriterForExtension() when it gets to the loaded library). -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] where the nested NodeCallbacks are called?
Trajce Nikolov wrote on Thursday, December 03, 2009 9:25 AM:
looks like nowhere. Here is the code in updatevisitor:
inline void handle_callbacks_and_traverse(osg::Node node)
{
handle_callbacks(node.getStateSet());
osg::NodeCallback* callback = node.getUpdateCallback();
if (callback) (*callback)(node,this);
else if (node.getNumChildrenRequiringUpdateTraversal()0)
traverse(node); }
All NodeCallbacks are supposed to call NodeCallback::traverse() in their
operator(); traverse is where the nested callbacks are called.
HTH,
--
Bryan Thrall
FlightSafety International
bryan.thr...@flightsafety.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Node::Description into ageneralized propertymechanism?
Robert Osfield wrote on Wednesday, December 02, 2009 4:11 AM: I've done something similar to this in the OSG in the osg::ArgumnetParser::Parameter class - this one uses a union internally like the Variant class above, with the twist that it's for passing in data to be set so it uses a pointer to each datatype rather than the actual data. The Parameter class is used to avoid the need for many different read(..) methods for each type. I've also adopted this technique in the osgDB::Input class to enable the same type of functionality with providing read(Parameter,...) that are really convenient to use. One could use that osg::ArgumnetParser::Parameter approach in the new scheme being discussed for getting data out of the container object in convenient and type-safe way. I agree, if we go with Variants, it would be best to store a type to be type-safe. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Node::Description into ageneralized property mechanism?
Chris 'Xenon' Hanson wrote on Tuesday, December 01, 2009 11:06 AM:
I'm sort of thinking out loud, on (e-)paper here, so feel free to
shoot
holes in this design:
We design a class called something like CompositeUserData (I dislike
this
name, and prefer something like UserPropertiesCollection). It is
allocated
only when requested by one of the UserData/Description/Property APIs.
In it is simply a container (STL map?) of some new class
UserProperty.
UserProperty could either be an abstract base class with a derived
implementation for each property type (UserData pointer, Description
string,
float, etc). Or, it could be a concrete implementation itself of a
single
class with a member or members that can store any of the possible data
types
(I think Visual Basic had something called a Variant
http://en.wikipedia.org/wiki/Variant_type ).
I don't have any preference either way, so perhaps others who have a
dog in
this race might comment on their feelings for the architecture.
A new API can be added like
setUserProperty(keyname, SOME_TYPE, value);
and
value = getUserProperty(keyname, SOME_TYPE);
Not sure if SOME_TYPE is a string or an enum.
We can prevent key name collisions between types, and avoid
considering the
whole issue of using getUserProperty with the wrong TYPE by
name-manging the
type into the actual keyname used to store the property. So you could
set a
STRING of keyname foo and a FLOAT of keyname foo and they would
co-exist
because they're actually stored as fooSTRING and fooFLOAT.
In the same way, we can implement the existing UserData and
Description
APIs with specialized types like DESC and UDATA, so that they
won't
collide with the generalized API.
The existing Description API seems to respect the order of the
Descriptions
and existing code might rely on that, so they'd probably be stored
with key
names like DESC1, DESC2, etc to preserve the order.
This seems overly complicated to me; couldn't we just rely on users
knowing the type they want for a given key, like we rely on them knowing
what subclass of UserData they want now? That way, UserPropertyContainer
is simply an std::mapstring,ref_ptrReferenced . The UserData API
would store its Referenced pointer, and the Description API could store
a vector of strings:
Pseudocode:
void setUserProperty(std::string key, Referenced* property) {
if ( !_userProperties ) { _userProperties = new
UserPropertyContainer(); }
(*_userProperties)[key] = property;
}
Referenced* getUserProperty(std::string key) { return _userProperties ?
(*_userProperties)[key] : NULL; }
void setUserData(Referenced* ref) { setUserProperty(osg.userdata,ref);
}
Referenced* getUserData() { return getUserProperty(osg.userdata); }
class DescriptionList : public std::vectorstd::string, public
Referenced {};
void getDescription(int i) {
DescriptionList* descList = getUserProperty(osg.descriptions);
if ( !descList ) { descList = new DescriptionList();
setUserProperty(osg.descriptions,descList); }
return (*descList)[i];
}
etc. etc. etc.
--
Bryan Thrall
FlightSafety International
bryan.thr...@flightsafety.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Best ways to render FE models with millions oftris and quads
Andrew Cunningham wrote on Wednesday, November 18, 2009 4:51 PM: OK, I think I have resolved the mystery. The VBO was being stalled by a setNormalBinding(osg::Geometry::BIND_PER_PRIMITIVE); If I remove that, and compare FPS, then the VBO performance is slightly better than the displaylist version Why do I use setNormalBinding(osg::Geometry::BIND_PER_PRIMITIVE); Because by definition, finite element geometry is a discretized geometry, so you want each element to have one normal. You don't want to smooth the surface. If anyone has a way to do that without using BIND_PER_PRIMITIVE .. let me know! BIND_PER_PRIMITIVE forces OSG into slow paths, so I don't think it was using the VBO in that case (even if it did still allocate them). To take advantage of VBOs, you need one of the other bindings. Using per-vertex indexed arrays also force you into slow paths; see osg::Geometry::arFastPathsUsed(). So, the obvious way is to duplicate the per-primitive normals over all the vertices in that primitive, but that will increase your memory usage significantly. There was a thread on this recently; you could search the archives, I think they talked about ways of compressing normals into vertex attributes to minimize the extra memory overhead. HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] why geode==null,please read my follow ing codes.Thanks。
Xiao Han wrote on Tuesday, November 17, 2009 10:13 AM: How can I get group's geodes? Thanks. The best way is to create a subclass of osg::NodeVisitor and override the visit(osg::Geode) function. There are lots of examples that do this, such as the osgcallback example. Wang Rui wrote: Hi Xiao Han, Check the root of 'road_deming.ive' first, is it really a geode? Cheers, Wang Rui 2009/11/17 Xiao Han () Hi,everyone, Please why gn==null in following codes? osgViewer::Viewer* viewer=new osgViewer::Viewer(); osg::Group*root= new osg::Group(); osg::Node*node=new osg::Node(); node=osgDB::readNodeFile(road_demimg.ive);//cow.osg); osg::Geode* gn=dynamic_castosg::Geode*(node); Thank you! Cheers, Xiaohan -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] std::vector instances from osg::geode derived classerror
Thorsten Werner wrote on Friday, November 13, 2009 1:02 PM: Really tried everything and changed some lines. But this error once i try to Code: osg::ref_ptrTGBaseWidget WidgNode01 = new TGBaseWidget(2,1); instead of Code: osg::ref_ptrTGBaseWidget WidgNode01 = new TGBaseWidget(1,1); so please anybody who has the time and energy. Could you please check the code? Hi again, Thorsten, Thanks for providing source code; it will help us help you much more than stack traces do! For example, I notice you haven't fixed the problem I identified in http://forum.openscenegraph.org/viewtopic.php?t=4083#19506 However, there is only so much we can do to help, and at some point you will have to just use a debugger (or even print out messages) to figure out what is going wrong and fix it. HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] std::vector instances from osg::geode derived classerror
Thorsten Werner wrote on Wednesday, November 11, 2009 9:56 AM:
int posX = 585;
int posY = 370;
std::vectorTGWidgetElement ElementLower;
for(int i=count_width; i0; i--)
{
ElementLower.push_back(TGWidgetElement(posX, posY,
WidgElementSideLower.png)); posX += 15;
posY += 15;
//this-addChild(ElementLower[count_width]);
}
I'm really stuck here. What am i doing wrong???
Group and other OSG Nodes declare operator= to be non-public so they
cannot be instantiated on the stack (which would easily lead to problems
with OSG's smart pointers); you have to dynamically allocate them.
Try something like this instead:
int posX = 585;
int posY = 370;
std::vectorosg::ref_ptrTGWidgetElement ElementLower;
for(int i=count_width; i0; i--)
{
ElementLower.push_back(new TGWidgetElement(posX,
posY,WidgElementSideLower.png));
posX += 15;
posY += 15;
//this-addChild(ElementLower[count_width]);
}
--
Bryan Thrall
FlightSafety International
bryan.thr...@flightsafety.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] std::vector instances from osg::geode derivedclasserror
Thrall, Bryan wrote on Wednesday, November 11, 2009 10:00 AM: Group and other OSG Nodes declare operator= to be non-public so they cannot be instantiated on the stack (which would easily lead to problems with OSG's smart pointers); you have to dynamically allocate them. I should've checked first; this is actually because they declare their destructor non-public (protected, actually). -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] std::vector instances from osg::geode derived classerror
Thorsten Werner wrote on Wednesday, November 11, 2009 10:31 AM: Ahhh. Ok that worked. But now i uncommented Code: this-addChild(ElementLower[count_width]); It compiles but gives a Segmentation Fault at startup. Not a lot of information to go on, but here's a WAG: count_width is counting down, but ElementLower is growing, so ElementLower[count_width] is not the same as the element you just passed to push_back(). HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] std::vector instances from osg::geode derived classerror
Thorsten Werner wrote on Wednesday, November 11, 2009 11:47 AM: Hi, It only gives a segfault if count_width is higher than 1. I've no idea what could be wrong... Try looking at it in a debugger and compare count_width with the current size of the vector. For example, if count_width is 5, your code does: ElementLower.push_back(new TGWidgetElement()); // vector size is now 1 addChild(ElementLower[5]); // there is no such element! HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting CullVisitor
Jean-Sébastien Guay wrote on Tuesday, November 10, 2009 10:55 AM: Are there advantages to modifying CullVisitor rather than overriding traverse(), other than one dynamic_cast per frame per node? I think if that's the only advantage, I'd personally prefer keeping all the code related to the node type local to the type itself, even if that node type were to be included into OSG. But that's a coding style concern, I just want to know what you think about this and if there's something I have missed. From experience, I can say that one dynamic_cast per frame per node can really add up to hurt performance :) -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Would someone be willing to help me diagnose aperformance issue?
Frank Sullivan wrote on Tuesday, November 10, 2009 3:26 PM: 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. I believe they refer to the number of Drawables, Vertices, etc. that are actually rendered. It appears that your slow app is rendering about 4-5 times the number of objects. Perhaps it has multiple cameras or render passes that the quick app does not? Perhaps models are getting added multiple times at the same location? How do the numbers change when you add a single model and how is that change different between the two apps? HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Would someone be willing to help me diagnose aperformance issue?
Frank Sullivan wrote on Tuesday, November 10, 2009 3:51 PM: 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). I haven't really dug into the stats stuff yet, but you can look at osgViewer/StatsHandler.cpp in the source to get a start. Basically, it uses osg::Stats, which has a map of strings (such as Number of unique Primitives) to values. The values must be updated somewhere in the code; likely, you can search for the string to figure out how exactly they are calculated. HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with DOF Nodes
Felipe Lemus wrote on Tuesday, October 27, 2009 1:57 PM:
tankDataType::tankDataType(osg::Node* n)
{
rotation= 0;
tank = dynamic_cast osgSim::DOFTransform* (n);
}
void tankDataType::updateTurretRotation()
{
rotation -= 0.01;
tank-setCurrentHPR( osg::Vec3(rotation,0,0) );
}
This code assumes that tanks is never null (i.e. that the top node of
the loaded file is a DOFTransform), but this is not guaranteed; the
dynamic_cast could return null, then updateTurretRotation() would
segfault.
You should use a NodeVisitor to find the DOFTransform in the loaded
model and pass that to the tankDataType constructor.
HTH,
--
Bryan Thrall
FlightSafety International
bryan.thr...@flightsafety.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Write osgAnimation callbacks into osg files - no Information available ?
p...@graphics.cs.uni-sb.de wrote on Wednesday, October 21, 2009 8:05 AM: Cedric Pinson wrote: Hi pp, Did you try to modify an osgAnimation example and add a osgDB::writeNodeFile of the root node to see if it writes the animation correctly in a osg file ? Cheers, Cedric Hi Cedric, yes I did, and this is exactly what is not working, and my original question. I took the example osgAninmationNode, exchanged the main procedure to write out an osg file. This was not working, no update callbacks in the file. In that file you create a class deriving from NodeCallback. And that seems to be the Problem, Instead of this I need to use a class from osgAnimation itself, otherwise the writer can't write it. You can look at src/osgPlugins/osgAnimation/ReaderWriter.cpp to see how to write your own classes to .osg format, for example. HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Write osgAnimation callbacks into osg files - no Information available ?
p...@graphics.cs.uni-sb.de wrote on Monday, October 19, 2009 3:14 AM: The reason you get no update callback in the .osg file is that osganimationnode uses a custom callback, AnimtkUpdateCallback, that the .osg writer doesn't know about. From the OpenSceneGraph-Data .osg files that have animation (such as robot.osg), it looks like osgAnimation::BasicAnimationManager is supported, so you could start with using that instead of AnimtkUpdateCallback. HTH, Had the same guess, but did not manage to get it to work. Example Code would be cool, so I could go on from this point, thx. Unfortunately, I am not familiar with osgAnimation, so I don't really know how to create one. I would recommend looking at the contents of robot.osg and comparing it to the interface of the osgAnimation classes; you could also look at the other osgAnimation examples (osganimationsolid seems to use BasicAnimationManager, for example). I tested that osgAnimation callbacks can be written to files using 'osgconv robot.osg robot2.osg' and they seemed to be written to robot2.osg just fine. Sorry I can't help further. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Write osgAnimation callbacks into osg files - no Information available ?
p...@graphics.cs.uni-sb.de wrote on Friday, October 16, 2009 4:32 AM:
Problem reconstruction :
osgAnimation Example osganimationnode, exchange the main proc. Instead
of creating a viewer write out a file, as this.
int main( int , char** )
{
osg::ref_ptr osg::Group root = new osg::Group ;
root-setInitialBound(osg::BoundingSphere(osg::Vec3(10,0,10),
30));
root-addChild(createAxis());
osg::MatrixTransform* node = setupAnimtkNode();
root-addChild(node);
if ( !root.valid() )
osg::notify( osg::FATAL ) Failed in createSceneGraph() !
std::endl ;
bool arg = false;
bool result = osgDB::writeObjectFile( * ( root.get() ) ,
animNode.osg ) ;
if ( !result )
osg::notify( osg::FATAL ) Failed in osgDB::writeNodeFile()
! std::endl ;
}
The reason you get no update callback in the .osg file is that
osganimationnode uses a custom callback, AnimtkUpdateCallback, that the
.osg writer doesn't know about.
From the OpenSceneGraph-Data .osg files that have animation (such as
robot.osg), it looks like osgAnimation::BasicAnimationManager is
supported, so you could start with using that instead of
AnimtkUpdateCallback.
HTH,
--
Bryan Thrall
FlightSafety International
bryan.thr...@flightsafety.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Loading a model
Giering Joseph wrote on Saturday, October 03, 2009 9:26 AM:
I have a problem to load a model by using this code:
// load model
osg::Node* pLoadedModel = osgDB::readNodeFile(
C:\Programme\ADTF\2.1.1\lib\OpenSceneGraph-2.6.1\bin\tour.obj );
if(!pLoadedModel) {
std::cout Error: Couldn't find model! std::endl;
}
m_pTransform-addChild(pLoadedModel);
GetRoot()-addChild(m_pTransform.get());
The readNodeFile can't find the tour object-file. Where needs the file
to be
stored? Must I compile the obj-plugin? How Can I compile this plugin?
In C and C++, you need to escape back-slashes within strings using
additional back-slashes, like so:
osg::Node* pLoadedModel =
osgDB::readNodeFile(C:\\Programme\\ADTF\\2.1.1\\lib\\OpenSceneGraph-2.6
.1\\bin\\tour.obj );
I think using forward slashes instead (which don't need to be escaped)
would work as well.
HTH,
--
Bryan Thrall
FlightSafety International
bryan.thr...@flightsafety.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to improve frame rate of my scene with lots ofcubes and cylinders?
Maurizio Lodo wrote on Friday, October 02, 2009 2:45 AM: Thanks for your replies!! I have been reading through this forum and googled a lot and it seems the best solution for my problem would be to create a simplified cylinder geometry (which I have done), divide all the cylinders into bins (by diameter, as they will have all the same length), and use geometry instancing to create several instances of the representative cylinder for each bin, translatated and rotated so that they would appear in the correct position in the scene. Would this sound sensible to you? If the diameter is the only part of the geometry that changes, you could even just use one instance of the cylinder and put a scale in the instance transform to get the correct diameter. BTW, I think Andrew is slightly incorrect: ShapeDrawable defaults to using display lists, so even though it appears to regenerate the vertex locations every frame, it does not. It only does that when the display list is dirtied (see osg::Drawable::draw()), so it is not as expensive as he made it seem. However, ShapeDrawable is very limited in certain ways (and Robert often laments creating it in the first place), such as in texturing IIRC, so you might be better off with using osg::Geometry instead anyway. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Set Node color
Bilal Zeidan wrote on Friday, October 02, 2009 3:10 PM: I am asking if some can help me to set a non shaded color to a node. In another words, I don't want the color of the node to be affected by the light source of the scene. In my case, I don't have a direct access to the node's drawables that's why I am using the node's material to set the color of the node. I tried to set the ColorMode of the material to be GL_DIFFUSE/GL_EMISSION but none of them has worked well. I also tried to activate and deactivate the light attribute of this node but I didn't get the desired result. My question is how can I set a single non shaded color to a loaded graphic model if I don't have access to its geometry? Thank you in advance. Have you tried using OVERRIDE when you set the ColorMode or GL_LIGHTING? i.e. stateset-setAttributeAndMode(colorMode, osg::StateAttribute::ON | osg::StateAttribute::OVERRIDE); or stateset-setMode(GL_LIGHTING, osg::StateAttribute::OFF | osg::StateAttribute::OVERRIDE); Without OVERRIDE, the model's settings for these attributes will be used instead of yours. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] integration of OSG inside an external openGL engine
Frederic Marmond wrote on Wednesday, September 23, 2009 10:03 AM: I'm making a study on how integrate OSG inside an external openGL engine. I know it's not the best use of osg, ok... :) So I used osgViewer::Viewer::setUpViewerAsEmbeddedInWindow() as a start. It's ok, as long as I don't modify the opengl state outside OSG. = how may I force OSG to consider the opengl state has changed (and so, re-apply all its states) ? I can answer this question: see the haveApplied*() functions in osg::State. Of course, Robert's answer will be easier though :) I'm not sure what the best way to get the State is; you might try attaching a preDrawCallback to the viewer's Camera, or perhaps GraphicsContext::setState() (via viewer.getContexts()). = using that technique, would I be able to cull / draw osg stuff in separate threads (handled by the hosting engine) ? thanks in advance for any answer or tips... -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgconv syntax
Travis Friedrich wrote on Thursday, September 10, 2009 11:31 AM: Where can I find a list of all the current supported writable formats? Use 'osgconv --formats' and look for writeNode or writeObject in the features list. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with a program in osg qsg
Brett Thomas Lee wrote on Tuesday, September 08, 2009 6:49 PM: Thank you! very much.I also have an another question.What is attach in mPreRenderCamera-attach(osg::Camera::COLOR_BUFFER,img.get()); code.If I attach an image to color buffer whenever I update the camera scene does the image gets automatically updated??or Do I need to attach it every frame?? I'm not certain which meaning of updated you mean here, so I will clarify: the image will not be updated during OSG's update traversal, it is updated during the draw phase. HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with a program in osg qsg
Brett Thomas Lee wrote on Tuesday, September 08, 2009 4:51 PM:
Hi,
Similar to Mr Paul I tried to modify my scene by calling update like
this
viewer.realize();
while(!viewer.done())
{
viewer.advance();
viewer.eventTraversal();
//viewer.updateTraversal();
mtLeft-setUpdateCallback( new RotateCB );
viewer.renderingTraversals();
viewer.setCameraManipulator(new osgGA::TrackballManipulator());
}
But nothing happened!!
If you comment out the update traversal, no update callbacks will be
executed. What Paul was suggesting is doing whatever RotateCB does in
while(!viewer.done()), like so:
viewer.realize();
while(!viewer.done())
{
viewer.advance();
viewer.eventTraversal();
//viewer.updateTraversal();
doRotateCBStuff();
viewer.renderingTraversals();
viewer.setCameraManipulator(new osgGA::TrackballManipulator());
}
--
Bryan Thrall
FlightSafety International
bryan.thr...@flightsafety.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Derived classes and ref_ptr
Martin Beckett wrote on Friday, September 04, 2009 5:20 PM: Hi, I have a class derived from PositionAttitudeTransform. It's simply an Adapter it contains no new variables but fixes up some methods for osg::PAT to be used in an existing design for some navigation routines. The existing navigation library is fixed I can't change it to understand osg::ref_ptr,=. Objects of the Adapter class need to be created on the stack in the library. Is there any way to define such a class so that it can be used as a regular class with objects on the stack in my library but still be reference counted in OSG? It's really not a good idea to mix stack-created objects with reference counting (when the reference count hits zero and the stack-created object is deleted, bad things happen), but if you're *REALLY SURE* that you can be careful about it, *still don't do it*, because eventually someone else will modify your code (it might even be a future you) who won't be as careful. HTH :) -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com P.S. You must be *REALLY REALLY SURE* to read this far, and if you are, I'll tell you the secret: all you have to do is declare a public destructor for your Adapter class to allow it to be created on the stack. See http://visualcpp.net/index.php?qID=65 for example. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Structs in GLSL shaders with OSG
Wyatt B. S. Earp wrote on Thursday, September 03, 2009 2:38 PM: I posted this via the mailing list, but it seems to never have gone through. I want to use a struct in my glsl shader. osg::StateSet::getOrCreateUniform allows for the specification of Uniform::Type, but I don't see an enumeration for struct. How would I create/set the uniform struct? You need to specify uniforms for each struct member, so they'd have names like mystruct.firstmember and mystruct.secondmember with appropriate types. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Nested transparent objects
Ben Axelrod wrote on Thursday, September 03, 2009 4:25 PM: I am trying to view transparent objects inside of other transparent objects. My objects are simple ShapeDrawables with some color and alpha transparency. I am seeing strange behavior where the inner object is sometimes completely hidden by the outer object depending on camera angle. Also, some of the object edges that should be visible are not. (Again, depending on camera angle). In the attached images: badalpha.png there is a small red cube partially inside of a larger green cube. they both have some transparency and you should be able to see through both objects. however, some edges of the green cube are completely hidden by the red cube. The desired behavior can be seen in badalphamodbyhand.png in which I modified to show what should be shown. This must be a common problem, but I searched the archives and it did not turn up much. my GL_DEPTH_TEST attribute is on as well as GL_BLEND. I am using OSG 2.6.0 with an NVidia series 7 graphics card. Is there some way to improve the transparency visualization? This is a common problem: OSG sorts at the granularity of Drawables and according to the bounding sphere's center, so it can get the rendering order wrong from certain points of view (for proper blending, distant transparent objects need to be rendered before nearer objects). For intersecting Drawables, there is no correct order, which is what you're seeing. To get correct behavior, you'd have to split your objects into separate Drawables so that they can be sorted, which may require splitting polygons (and for dynamic objects, splitting the polygons every time the objects move or change shape). HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Paging strategies for road tiles
Björn Blissing wrote on Thursday, August 27, 2009 2:32 AM: Hi Brian, Yes, my tiles are a lot larger than 2000 meter. The radius of the first tile is 9008.5 m, and the road segment contained in that segment is 18017 m. But should really the range value be connected to the tile size?? I my mind it should work in the way that if my eye point comes within the specified range the LOD tile should appear. And by within range I mean that distance from the eye point to the edge of the bounding sphere of the tile. But maybe I have completely missunderstood the concept here?? The LOD radius is tested using the distance from the eye point to the center of the LOD (which defaults to the center of the bounding sphere), so if you want them to appear 2000 meters before the edge of the bounding sphere, you need to set the LOD radius to 2000+bounding sphere radius. Hi Bjorn, It looks like the problem is your tiles are larger than 2000 m radius. Try setting the range to the tile radius, or some multiple (1.5 * radius, 2.0 * radius). Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. * -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: Björn Blissing bjorn.bliss...@vti.se Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/26/2009 11:56AM Subject: [osg-users] Paging strategies for road tiles Hi all, My application involves road vehicles driving down long roads. Approx 1000 km of continuous road. The problem is that I can only hold about 100 km of road before system memory runs out. Plan B then naturally falls on some sort of paging strategy. I rewrote the software so it generates .ive files containing about 10-30 km road. Then the plan was to use pagedLOD to page in the files when needed. My test program only uses four of these tiles, but I do not seem to get it right. My pagedLOD nodes all lie under the scene graph root. Each one only contains a reference to the corresponding .ive file and a range set from 0 to 2000 (since I don't want the next geometry to be paged in until I am closer than 2000 meters). The center of each pagedLOD node is set to the center point of the geometry in the file and the radius is set to half the length of the road in the file. But no geometry is ever paged in. If I set the center to (0, 0, 0) the geometry will page in the first segment of road, but then the geometry disappears when I traveled more than 2000 meters. The other tiles never shows up. I am obviously missing something when setting up my pagedLOD. If someone could give me a hint I would be most thankful. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] checking StateAttribute::OVERRIDE
Helbig, Yuen wrote on Monday, August 24, 2009 5:37 PM:
Does anyone know how to check if the StateAttribute::OVERRIDE flag is
set on
a StateSet?
Yuen Helbig
Perhaps something like the following:
osg::StateAttribute::Type ssType = osg::StateAttribute::TEXTURE; // or
the type of whatever StateAttribute you want
if (0 != stateset-getAttributePair(ssType)-second
StateAttribute::OVERRIDE)
{
osg::notify(DEBUG_FP) StateAttribute type ssType has
OVERRIDE set std::endl;
}
--
Bryan Thrall
FlightSafety International
bryan.thr...@flightsafety.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Orienting a model (matrixtrans) toward a targetlocation?
Kris Dale wrote on Friday, August 21, 2009 3:51 PM: Bahahahaha. Brilliant! The makeRotate(from, to) works like a champ! From here I think it's just a matter of figuring out how to animate the effect (slow turning toward the target location...) This is great though! I'm definitely going to have to dive into the source and see how it goes about coming up with this orientation because after spending a few days on this my brain is absolutely about to catch FIRE about it. hahaha. Matrix::getRotate() and Quat::slerp()? -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Orienting a model (matrixtrans) toward atarget location?
Chris 'Xenon' Hanson wrote on Thursday, August 20, 2009 5:13 PM: Tony Horrobin wrote: Hi Kris, Is the target moving too? Cheers, You know, my first contact with our own Paul Martz was way back in the late 90s when he gave me some code for a glLookAt type implementation. I'll see if I still have it around -- it still is deeply buried in some old 3d code in our application. There's osg::Matrix::makeLookAt() -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Writing single plugin to handle multiple extensions
Rick Pingry wrote on Friday, August 07, 2009 4:52 PM: Is there a way already to force the viewer to load a specific library based on some environment variable or better yet a command line parameter? would that be sufficient? Yes, osgviewer supports '-l libname' (that's a lower-case L) to load a specific library. Once the library is loaded, it will be used to load all extensions it says it supports (via acceptsExtension()). -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] glMultiTexCoord4f , OSG with OGL code
Pau Moreno wrote on Wednesday, August 05, 2009 12:22 PM: Since I know, OSG doesn't have support for geometry shaders, does it? I'll check it again. It has had support since January, 2008, according to the SVN log; see osg::Shader. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback
Brian R Hill wrote on Wednesday, August 05, 2009 3:05 PM: I think this is the common case and I always understood postdraw to mean that the camera is done with rendering/drawing. I've always thought of it as the last chance to draw something, essentially a hook into the drawing phase to integrate things that don't fit well in the scenegraph architecture. So, if you wanted to add things to be done before image copy, it should be part of the camera's subgraph. I guess I could do this. Create a custom drawable that call the 3rd party function. The difficulty will be guaranteeing it's the absolutely last thing drawn. The postdraw makes this easy. What about inserting a POST_RENDER Camera under the camera with the DrawCallback attached to it? -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: J.P. Delport jpdelp...@csir.co.za Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/05/2009 03:53PM Subject: Re: [osg-users] RenderStage::draw order ofcopyTexture and PostDrawCallback Hi, Brian R Hill wrote: Hi JP, I was trying to determine if the current order (copy image, then call postdraw) was deliberate for specific reasons, or if it just got coded that way. I think it was deliberate; however, I didn't write the code. I understand where you would want the copied image to be available in the postdraw, I think this is the common case and I always understood postdraw to mean that the camera is done with rendering/drawing. So, if you wanted to add things to be done before image copy, it should be part of the camera's subgraph. but I also understand where you would want the postdraw to apply to the image before the copy. It just depends on what the intended purpose of the postdraw is. Personally I feel the postdraw should occur before the copy and that the copied image should be accessed on the cpu side during the update phase. Would it not be a frame late then? I understand your need for more flexibilty ito processing order and copying. I would suggest you have a look at osgPPU where you have more control over these things. jp Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. * -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: J.P. Delport jpdelp...@csir.co.za Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/05/2009 03:27PM Subject: Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback Hi, Brian R Hill wrote: Hi JP, I'm using a 3rd party library to do filtering on the rendered image. They do all their magic using opengl in a function call from the postdrawcallback. Here's what it currently does: draw - FBO - copy to cpu - postdraw The postdraw operates on the FBO after it's been copied to the cpu and I never see it. Here's what I want to do: draw - FBO - postdraw - copy to cpu I want to access the image with the filtering effects included. Does this make it clearer? Yes. My fallback is to not attach an image to the FBO and do the copying myself in the postdrawcallback after the filtering. This sounds OK to me, do you have problems with it? AFAIK you cannot change the order for a single FBO camera. The only other option I can think of (if you don't want to manually copy) is to create a second FBO camera solely for copying the result of the filtering (input texture to the second camera) to an osg::Image. Then you have draw - FBO1 - postdraw - FBO2 - to CPU jp Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. * -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: J.P. Delport jpdelp...@csir.co.za Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/05/2009 02:17PM Subject: Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback Hi Brian, Brian R Hill wrote: Sorry about the multiple posts/wrong subjects. Another copy/paste artifact. Folks, I'm doing offscreen rendering using fbos with attached images. I'm also using the postdrawcallback to do
Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback
Thrall, Bryan wrote on Wednesday, August 05, 2009 3:22 PM: Brian R Hill wrote on Wednesday, August 05, 2009 3:05 PM: I think this is the common case and I always understood postdraw to mean that the camera is done with rendering/drawing. I've always thought of it as the last chance to draw something, essentially a hook into the drawing phase to integrate things that don't fit well in the scenegraph architecture. So, if you wanted to add things to be done before image copy, it should be part of the camera's subgraph. I guess I could do this. Create a custom drawable that call the 3rd party function. The difficulty will be guaranteeing it's the absolutely last thing drawn. The postdraw makes this easy. What about inserting a POST_RENDER Camera under the camera with the DrawCallback attached to it? Er... to clarify: insert a Camera under your main camera and set it to POST_RENDER. Then attach your DrawCallback to the POST_RENDER camera. The DrawCallback should happen before the main camera's FBO copy to Image. -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: J.P. Delport jpdelp...@csir.co.za Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/05/2009 03:53PM Subject: Re: [osg-users] RenderStage::draw order ofcopyTexture and PostDrawCallback Hi, Brian R Hill wrote: Hi JP, I was trying to determine if the current order (copy image, then call postdraw) was deliberate for specific reasons, or if it just got coded that way. I think it was deliberate; however, I didn't write the code. I understand where you would want the copied image to be available in the postdraw, I think this is the common case and I always understood postdraw to mean that the camera is done with rendering/drawing. So, if you wanted to add things to be done before image copy, it should be part of the camera's subgraph. but I also understand where you would want the postdraw to apply to the image before the copy. It just depends on what the intended purpose of the postdraw is. Personally I feel the postdraw should occur before the copy and that the copied image should be accessed on the cpu side during the update phase. Would it not be a frame late then? I understand your need for more flexibilty ito processing order and copying. I would suggest you have a look at osgPPU where you have more control over these things. jp Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. * -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: J.P. Delport jpdelp...@csir.co.za Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/05/2009 03:27PM Subject: Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback Hi, Brian R Hill wrote: Hi JP, I'm using a 3rd party library to do filtering on the rendered image. They do all their magic using opengl in a function call from the postdrawcallback. Here's what it currently does: draw - FBO - copy to cpu - postdraw The postdraw operates on the FBO after it's been copied to the cpu and I never see it. Here's what I want to do: draw - FBO - postdraw - copy to cpu I want to access the image with the filtering effects included. Does this make it clearer? Yes. My fallback is to not attach an image to the FBO and do the copying myself in the postdrawcallback after the filtering. This sounds OK to me, do you have problems with it? AFAIK you cannot change the order for a single FBO camera. The only other option I can think of (if you don't want to manually copy) is to create a second FBO camera solely for copying the result of the filtering (input texture to the second camera) to an osg::Image. Then you have draw - FBO1 - postdraw - FBO2 - to CPU jp Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. * -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: J.P. Delport jpdelp...@csir.co.za Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/05/2009 02:17PM Subject: Re: [osg-users] RenderStage
Re: [osg-users] OSG and shaders
Hadrien Thomas wrote on Tuesday, August 04, 2009 10:57 AM: Ok. It's going to be a lot of work for me I guess :P Thank you for your help! Perhaps osgUtil::ShaderGenVisitor and the osgshadergen example can help you out? They were designed to reproduce the fixed functionality pipeline in shaders. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] glMultiTexCoord4f , OSG with OGL code
Pau Moreno wrote on Tuesday, August 04, 2009 3:18 PM: I'm trying to use multitexture in a class that inherit from Drawable. I use glMultiTexCoord4f inside of the drawImplementation, because I need this function to work with this parameters I have in a geomtryShader, but by some reason a get a Segmentation Fault while I'm using it... Shall I have to activate something? I've read something about activate the texture in the StateSet, but I don't know what exactly do... You need to tell OSG about any OGL calls you make; otherwise, it gets confused about the current OGL state. See osg::State::haveAppliedAttribute(), haveAppliedMode(), etc. If that doesn't help, can you provide more details, such as a complete simple test case (a model or code perhaps modified from osgviewer) showing what you're doing? -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Reload shader sampler2D for each drawable
Maxime BOUCHER wrote on Friday, July 31, 2009 7:58 AM: bthrall wrote: The shader has a sampler2D uniform that needs to be set to the texture unit you want to use; as long as you attach a different Texture2D to each geode/drawable on that texture unit, the shader will see that geode/drawable's texture. Well, the shader can only access textures belonging to the same stateset, right? For example: [Image: http://img7.hostingpics.net/pics/398942graphe_shader_textures.jpg ] (http://www.hostingpics.net/viewer.php?id=398942graphe_shader_textures.j pg) Texture0 is the sampler2D given to the shader (well, its unit). I would like to load texture0 as texture1 while OSG draws drawable1, and load texture0 as texture2 while OSG draws drawable2. I guess I could set a shader for each, but first, the scenegraph can be of any complexity, then it could need a great number of shaders, it would be bad. Moreover, I'm not sure on how they will overwrite each other (if so). Do you still think I can do this without callbacks? The shader can access the current texture of any texture unit, depending on what texture unit the sampler2D uniform is set to. In your example, if texture0 (meaning the osg::Texture2D object containing texture0) is attached to the root stateset in unit 0, then the root stateset should have a uniform for the sampler2D with value '0'. Then, if texture1 and texture2 are attached to their statesets in unit 0, the shader will use whatever texture is in unit 0 when it renders geode1 and geode1: Render geode1: current texture in unit 0 is texture1, sampler2D uniform has value '0', so shader uses texture1 Render geode2: current texture in unit 0 is texture2, sampler2D uniform has value '0', so shader uses texture2 If I attach another geode to root, geode3, with no stateset at all, the shader will use texture0 because that is the texture in unit 0 when geode3 is rendered. HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Reload shader sampler2D for each drawable
Maxime BOUCHER wrote on Thursday, July 30, 2009 8:24 AM: Hi, I'm looking for reloading the texture I send to a shader I put on the top of the scene graph. As every geode/drawable (it depends on the model) as a different texture, I'd like to reload the good one for each. I tried to do so using the geodes' drawables' update callbacks in the callbacks example but it always takes the last geode/drawable 's visited texture. As the FFP does it, I'm pretty sure I can too. Do you know how? The shader has a sampler2D uniform that needs to be set to the texture unit you want to use; as long as you attach a different Texture2D to each geode/drawable on that texture unit, the shader will see that geode/drawable's texture. You only need update callbacks if the texture changes from frame to frame. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Deadlock when loading osg.dll, singletons are evil
Tanguy Fautre wrote on Wednesday, July 29, 2009 12:37 PM: The DllMain problem is quite well documented (cf. the MSDN links from my previous post). The thing is that an illegal use of DllMain is quite similar to a race condition. Most of the time, everything just seems to work. Our application has already about 10 threads up and running before osg.dll is being loaded, significantly increasing the chance of a deadlock. I would expect most OSG-based applications to do just fine as they start using OSG (and therefore osg.dll) when still single threaded. Because our application is quite multithreaded, it's not the first time we've uncovered thread-safety bugs in what are supposed to be quite stable libraries. Recently, we've just found a couple of thread-safety issues with LibCurl and OpenSSL (their developers have accepted these as genuine defects and are fixing these issues). Google found a few (not many) posts related to these issues, but due to the lack of proper investigations they often got dismissed. The links you posted explicitly said that creating synchronization primitives is allowed in DllMain; the problem is acquiring them when other threads are trying to acquire the loader lock (to enter some DllMain function). Are you saying that the problem is the mutex used in creating the singletons, or is there some other limitation of DllMain that you think OSG is violating? A simple test case demonstrating the problem you're describing would be helpful, I think. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: 29 July 2009 17:28 To: OpenSceneGraph Users Subject: Re: [osg-users] Deadlock when loading osg.dll, singletons are evil Hi Tanguy, We've encountered several times a random deadlock that would happen when starting our application. After some playing around, we've identified the problem to be quite a subtle one. What you're describing makes sense in some way, but I have two questions: 1. Why have there not been more discussions about random deadlocks in the recent past? For example, we have not experienced anything resembling what you describe. I am not an expert in Win32 programming, so what you describe may well be true, but we haven't encountered this, and I'm pretty sure if it were such a widespread problem we'd have heard of it on this list before. Of course, that's not proof in itself that the issue is not there, but it's an indication that it might be something on your side rather than a widespread problem. 2. If singletons are bad practice as you say, what do you propose to replace them? I'm always a bit skeptical of sentences like Google is full of papers [saying that singletons are broken]. People have a tendency to be extreme in their judgements, and if someone finds an instance where singletons give bad results, they will often start saying that they are bad in all cases (and inevitably post to their blog about it). It's a tool for a job, and the developer has to know when to use it and when not to. That's the developer's responsibility, not the tool's. I'm not saying that all uses of singletons in OSG are good ones (most obviously because I've probably not personally seen all of them) but singletons are useful (they give a single point of access to something - data, functionality) and that has to be replaced by something else if singletons have a downside in some/most/all(?) situations. J-S -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Reader/Writer implementation
Andrew V. Moore wrote on Monday, July 27, 2009 2:05 PM: I was wondering if anyone could point me in the right direction for examples of using a reader/writer with text files. Any help would be appreciated. Thank you. I think you're asking for an example of using a osgDB::ReaderWriter to write scenegraphs to text files and read them back? There are a number of them, including .osg, COLLADA (XML text files), .dot. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Specular Highlight with Vertex Colors?
Andrew Burnett-Thompson wrote on Friday, July 17, 2009 10:42 AM: However so far I can see the only way to add specular is via a StateSet. I previously had one stateset per object, but this consumed too much memory, so now have a shared stateset I assume you're referring to your statement here: http://forum.openscenegraph.org/viewtopic.php?t=3121 Where you say moving from a StateSet per Geode to a shared StateSet saved you 250MB. We don't have any details on how you're creating those StateSets, but the StateSet itself is only about 192 bytes, so the rest of the memory savings probably come from all the StateAttributes you must be adding to the StateSets. Perhaps if you shared the StateAttributes as much as possible, you could still use a StateSet per Geode (such as for adding specular) with a much smaller memory footprint (closer to 36MB for your 20 object model). I'm assuming a lot about what you were doing, though, so feel free to shoot me down if some of my assumptions are wrong :) -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to set per vertext attributes using osg
Jason Daly wrote on Friday, July 10, 2009 1:25 PM: Jean-Sébastien Guay wrote: OSG sorts by state to minimize state changes, but I'm not sure how it does the sort. I believe the state sort is done using the compare() method of StateAttribute. In the case of Uniforms, the comparison is pretty thorough (first data type, then number of elements, then actually comparing the data values of each element). The facility is there for comparing StateSets and StateAttributes, but is disabled (see osgUtil::RenderBin::sortByState()) for performance reasons. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to set per vertext attributes using osg
Bob Youmans wrote on Wednesday, July 08, 2009 3:51 PM: Hi all, I'm trying to figure out the best method to pass per vertex attributes to shaders using osg and I can't seem to find many examples of attribute use. My guess is there's a reason for that and I should probably code up a uniform array of some kind instead. I need to pass thickness as an attribute and that varies with the geometry / osg::Geode. I've studied the osg::Drawable and its attribute types, and the osg::Program and its addBindAttribLocation, but I can't find any examples of the callback or other mechanism to actually get the data set into the attributes from the scenegraph. I must be missing something, and I'm really new at this shader stuff. Can anybody point me in the right direction? Should I not try to use shader attributes, but instead use a uniform array and look up my data in there? If I do use shader attributes, where's an example? Using a normal array is unlikely to allow a big enough array for all your vertices :) See osg::Geometry::setVertexAttribArray(), setVertexAttribBinding(), etc. It doesn't look like there are any examples for using vertex attributes, though. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with blending when using floating point FBO
Jonathan Richard wrote on Tuesday, July 07, 2009 7:28 AM: Glad you got it working! Is there a reason you didn't just attach an osg::Texture to your camera and set the number of samples greater than 1 in the attach call? Well I did attach a texture to my camera and set the number of samples greater than 1...see: osg::ref_ptrosg::TextureRectangle offscreenTexture = new osg::TextureRectangle; offscreenTexture-setTextureSize(WIDTH, HEIGHT); offscreenTexture-setFilter(osg::TextureRectangle::MIN_FILTER,osg::Textu re2D::LINEAR); offscreenTexture-setFilter(osg::TextureRectangle::MAG_FILTER,osg::Textu re2D::LINEAR); offscreenTexture-setSourceFormat(GL_RGBA); offscreenTexture-setSourceType(GL_FLOAT); offscreenTexture-setInternalFormat(GL_FLOAT_RGBA32_NV); osg::Camera* camera=m_viewer-getCamera(); camera-setClearColor(osg::Vec4f(0,0.0f,0.0f,1.0f)); camera-setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); camera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT); camera-attach(osg::Camera::COLOR_BUFFER0, offscreenTexture.get(),0,0,false,8,4); then in my draw call back I just get the resolved fbo that osg fills with the glBlitFramebufferEXT call. This seems to work, I don't know if there is better or cleaner solution to my problem. By the way I was wondering why osg do not bind the resolved fbo instead of the multisampled fbo in order to allow subsequent glReadPixels call. If not I don't understand why the glBlitFramebufferEXT is automatically performed. When you attach a texture, OSG will fill the texture with the contents of the FBO automatically; you don't need to do the glReadPixels, just use the texture. By the way, if you change OpenGL state, be careful that you restore the previous state or tell OpenSceneGraph about the changes you make (via haveAppliedMode(), haveAppliedAttribute(), etc.); otherwise OpenSceneGraph will get confused about what the current OpenGL state is. you are refering to the binding call ( fbo-apply(state,osg::FrameBufferObject::READ_FRAMEBUFFER))? As I said before I'm not sure if my approach is the best one. I just looked at the osg code and found a way to get my own working. I saw (with your held) that a resolved fbo was automatically generated when drawing to a multisampled fbo so I just get it in my draw callback (getMultisampleResolveFramebufferObject()) then bind it in order to be able to read it. Yes, binding the fbo (and any other OpenGL state changes you do) should be reported to OSG or restored to their original state before leaving the draw callback. HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with blending when using floating point FBO
Jonathan Richard wrote on Monday, July 06, 2009 4:04 PM: Ok I was able to get it working by getting the resolved fbo using the RenderStage::getMultisampleResolveFramebufferObject method. Here a subset of my code in the draw callback: osgViewer::Renderer * renderer = static_castosgViewer::Renderer*(renderInfo.getCurrentCamera()-getRend erer()); osg::FrameBufferObject *fbo=NULL; fbo=renderer-getSceneView(0)-getRenderStage()-getMultisampleResolveFr amebufferObject(); // Bind the fbo to be read fbo-apply(state,osg::FrameBufferObject::READ_FRAMEBUFFER); // Specify a color buffer as the source for the subsequent call of glReadPixel glReadBuffer(GL_COLOR_ATTACHMENT0_EXT); float* tempbuf32Bits = new float[WIDTH*HEIGHT]; glReadPixels(0, 0, WIDTH, HEIGHT, GL_RED, GL_FLOAT, tempbuf32Bits); Glad you got it working! Is there a reason you didn't just attach an osg::Texture to your camera and set the number of samples greater than 1 in the attach call? By the way, if you change OpenGL state, be careful that you restore the previous state or tell OpenSceneGraph about the changes you make (via haveAppliedMode(), haveAppliedAttribute(), etc.); otherwise OpenSceneGraph will get confused about what the current OpenGL state is. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to set uniform is shaders by vertex
Rabbi Robinson wrote on Wednesday, July 01, 2009 9:50 AM: Hi, Is there any way I can set the uniforms by vertex? I know uniforms are in stateset. There are some attribute for vertex I need to set in shaders for each vertex. How can I do it? Uniforms are not set by vertex; you are wanting vertex attributes, which you can set in osg::Geometry using setVertexAttribArray or setVertexAttribData. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with blending when using floating point FBO
Jonathan Richard wrote on Tuesday, June 30, 2009 10:36 AM: you have to use glBlitFramebuffer to copy the multisample FBO to a FBO without multisampling to resolve the samples to a texture; this is what osgUtil::RenderStage does when you attach an osg::Texture and set the samples to 1. I'm not sure about the result of the glBlitFramebuffer operation...what is the result of this copy? Is it the original FBO without beeing multisampled? The result is an FBO without multisampling whose buffers are filled by combining the multiple samples from the multisample FBO together. If you just want to render to multisample buffers and never need to read back from those buffers (such as in a shader), you can do it; otherwise, I think you are out of luck. What do you mean by never need to read back from those buffers such as in a shader? You can render to multisample buffers, but to use the results in a shader or read back the data for use on the CPU, you must resolve them to a non-multisample form (Image or Texture). For example, if you render your scene to a depth buffer using a FBO, you either attach a (non-multisample) Texture, or you can attach a multisample RenderBuffer. If you want to use the latter depth buffer in a shader, you need to blit it to another FBO with a Texture attached, at which point it will no longer be multisampled. In the release note of osg 2.6.1 it says: OpenGL Multi-sample FrameBufferObject support. In fact what does it means? I do not really undestand in what configuration the multisample FBO can be used. It means you can render to multisample RenderBuffers. This is useful because now you can (for example) render to a multisample depth buffer in FBO and then use that as the depth buffer for the actual scene render, whereas before if you used an FBO, you could only get a non-multisample depth buffer (which causes problems when your actual scene render is multisampled). I haven't tried that particular usage (and again, I'm not an expert), though. HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with blending when using floating point FBO
Jonathan Richard wrote on Tuesday, June 30, 2009 3:09 PM: The result is an FBO without multisampling whose buffers are filled by combining the multiple samples from the multisample FBO together. Ok so the FBO multisampling is supported but not directly as it said on http://www.opengl.org/wiki/GL_EXT_framebuffer_object_More_about_FBOs Are multisample Render_To_Texture (RTT) supported? Not directly. You need GL_EXT_framebuffer_multisample and you would have to copy the contents of the AA-FBO to a standard RTT. you have to use glBlitFramebuffer to copy the multisample FBO to a FBO without multisampling to resolve the samples to a texture; this is what osgUtil::RenderStage does when you attach an osg::Texture and set the samples to 1. I looked at the code in the osgUtil::RenderStage::DrawInner method but it seems to depend on a call of the osgUtil::RenderStage::setMultisampleResolveFramebufferObject(osg::FrameB ufferObject* fbo) that seems to be never called. Does it means that I have to call it by myself? Maybe I could perform the blit by myselft instead of calling this method? I saw an old post about that (see the post named Setting the resolve FBO for multisampled RTT on 8/27/08) but it was not clear what to do. You do not have to call setMultisampleResolveFramebufferObject(). See RenderStage::runCameraSetUp(), which handles cameras with attachments. In particular, _resolveFbo is set due to multisampling on line 495 or so. The blit happens on line 910. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] GoogleMode
Adam Wise wrote on Monday, June 29, 2009 12:14 PM: I tried your suggestion, osgconv -o GoogleMode [model 1.flt] [model 2 .dae]. Didn't work. All osg did was post up the list of all the available options OSG_DATABASE_PAGER_PRIORITY mode etc etc etc. Is it safe to assume that GoogleMode is not available? http://www.openscenegraph.org/projects/osg/wiki/Support/KnowledgeBase/Co llada Under the collada reader/writer option, GoogleMode is there. How would I be able to access it? You want capital o, O, as in: 'osgconv -O GoogleMode' to set the options string -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] using CullVisitor
James Buckthorpe wrote on Monday, June 29, 2009 1:25 PM: Yes I am already using the osgUtil::PolytopeIntersector to work out whether the object is inside the FOV. However I am finding that the list of intersections includes my node of interest regardless of whether it has been culled or not due to another object or objects being in the way. How do I go about check whether the object has been culled?. My attempts to use the CullVisitor (as above) failed. In general with OpenGL (and including OpenSceneGraph) there is no culling based on whether other objects are in the way (the depth buffer handles this), unless you use occluders (see for example osg::OccluderNode and osg::OcclusionQueryNode; perhaps those will help you). HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with blending when using floating point FBO
Jonathan Richard wrote on Monday, June 29, 2009 2:19 PM: How did you test that setting both to 4 didn't work? This is how I tested it: ... // code in MyCameraDrawCallback glReadBuffer(GL_COLOR_ATTACHMENT0_EXT); float* tempbuf32Bits = NULL; tempbuf32Bits = new float[500*500]; glReadPixels(0, 0, WIDTH, HEIGHT, GL_RED, GL_FLOAT, tempbuf32Bits); All pixels that I read back are set to -431602080 (not the intended value). If I called camera-attach(osg::Camera::COLOR_BUFFER0, offscreenTexture.get(),0,0,false,0,0) it is working (without multisampling) glReadPixels does not work with a multisample FBO (check glGetError after your glReadPixels to see); you have to use glBlitFramebuffer to copy the multisample FBO to a FBO without multisampling to resolve the samples to a texture; this is what osgUtil::RenderStage does when you attach an osg::Texture and set the samples to 1. Note that the osg::Texture will not be multisampled because the multisample RenderBuffers are resolved during the blit to texture. You mean that this is no way to get multisample when using my osg::TextureRectangle? It so, what are the alternatives? Using a osg::Image? Ideally I need to support 32 bits floating point blending and multisampling in my project. Do you think this is possible? In OpenGL, AFAIK, there is no way to get a multisample texture (and OpenGL doesn't do multisampling when it samples a texture either). If you just want to render to multisample buffers and never need to read back from those buffers (such as in a shader), you can do it; otherwise, I think you are out of luck. Wish it were different, because I'd love to have the ability to read multisample textures too! -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] maya plugin, anyone interested?
Rabbi Robinson wrote on Friday, June 26, 2009 12:34 PM: I should probably have used .ive file. I didn't consider such possibility ver carefully when I started. There is an other fellow doing exactly that for OpenSG, except for OpenSG use XML file format which I think is really cumbersome. One reason for the intermediate binary format is that it embeds texture files as opposed to a reference to the files. For our team, we have all the artists doing their modeling job on separate computers and it's just easier for us to pack the whole scene into just one file and send to the programmers. And it seems maya support sound for animation, so the sound would be saved in the intermediate file format too. I don't know how introspection works in OSG. If I create a new class in Maya's exporter and pack it into .ive file. Can it be read correctly in OSG? Perhaps the osga or zip plugin could help with keeping all the files together? -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with blending when using floating point FBO
Jonathan Richard wrote on Friday, June 26, 2009 3:30 PM: Hi, I set the color by using a fragment shader and the 32 bits floating point blending seems to be working now. I would like to use multisampling in my FBO. How can I configure that? Is it only by setting the method: Camera::attach(BufferComponent buffer, osg::Texture* texture, unsigned int level, unsigned int face, bool mipMapGeneration, unsigned int multisampleSamples, unsigned int multisampleColorSamples) ? What is the difference between the parameter multisampleSamples and multisampleColorSamples? I tried to set both at 4 but that did not work. I'm not an expert, but I recently dug into FBOs, so hopefully I can help. Yes, that's the way to configure multisample FBOs. See http://www.opengl.org/registry/specs/NV/framebuffer_multisample_coverage .txt for the difference between multisampleSampls and multisampleColorSamples How did you test that setting both to 4 didn't work? Note that the osg::Texture will not be multisampled because the multisample RenderBuffers are resolved during the blit to texture. On Tue, May 26, 2009 at 11:09 AM, Jonathan Richard jonathan.richa...@gmail.com wrote: Ok thank you for the advice. I'm not very familiar with the shader programming yet, but I'm suppose to get into it soon. The problem that I see is how to get access to the facet from the shader. If I'm into a fragment shader I'll probably have no idea from which facet come each fragment. Is it right? Maybe I have to use a geometry shader? Or maybe I can perform the blending by myself into a fragment shader? You can tell me if you have any clue about that. I'll give you a little more of precision about my problem. The blending seems to be working when the alpha of the front facet is different from 1. For exemple if I define Rd = (2e-3, 0.0, 0.0, 1.0) // RGBA Rs = (6e-9, 0.0, 0.0, 0.4) //RGBA In theory: Rd = Rs + (1-As)Rd Rd = 6e-9 + (1-0.4)*2e-3 = 1.26e-3 In practice I get: 0.001259 For now, the problem seems to occur only when As =1. Thanks, Jonathan 2009/5/26 J.P. Delport jpdelp...@csir.co.za Hi, Jonathan Richard wrote: |// Tell to sort the mesh before displaying it |AFAIK OSG does not sort at the triangle level, there is an option to make the sorting happen at a primitive level, but I think the default is sorting on bounding sphere. I take this line (and the comment) from the osgblendequation example. You think that I should not do this call? No, the call is fine. What I'm saying is that blending and transparency is (depending on the blend equation) dependent on the order in which things are rendered, so one cannot assume (when making off-line calculations) that all the geometry is perfectly sorted (think e.g. intersecting objects). |offscreenTexture-setSourceType( GL_UNSIGNED_BYTE); |Should this not also be GL_FLOAT? yes sorry it is a copy paste error. I call offscreenTexture-setSourceType(GL_FLOAT) and offscreenTexture-setInternalFormat(GL_FLOAT_RGBA32_NV). |I can also not see from the code if OpenGL lighting is enabled. Do you disable lighting in your app? No I wasn't but I disable it now and I see no change in the result OK. I'm running out of ideas to try help. I cannot from just reading the code see any more problems. I'd suggest using the ARB modes and trying a few other machines. I'll also try find some of our test code for float blending. Another option is to use shaders to explicitly set the colours of two facets (to eliminate any fixed function interference) and see how they blend. jp Here a update of the code with the correction in yellow: The colors are attached by setting the ColorArray of the drawables of each Geode like this: int geodesNb = m_entityVectorOfGeodeVector[0].size(); osg::Geode* aGeode; int drawablesNb; osg::Drawable* aDrawable; osg::Geometry* aDrawableGeometry;
Re: [osg-users] Cygwin Compile Question OSG 2.8.1
Christopher Wang wrote on Wednesday, June 10, 2009 8:27 AM: Hi, That didn't either. Maybe I missing some step in the setup. What I did was: Ran Cygwin's setup.exe to install OpenGl, Cygwin, GCC, and several of the pre-reqs I unzipped the latest source (2.8.1) into /home/username/OpenSceneGraph-2.8.1 I made a folder /home/username/buildOSG Did ccmake ../OpenSceneGraph-2.8.1 Did a configure Fixed the OpenGL path to it pointed to the parent of the folder GL Did another configure Did a generate Did a make Then it fails about 15% on make!! I ideas what step I'm missing? I see on the Cygwin list that Alberto Luaces is proposing to add an OSG package: http://cygwin.com/ml/cygwin-apps/2009-06/msg00095.html So within the next couple of days you should be able to see how he built it. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Multidisplay FBO performance
I have a multiple display system with an NVIDIA 8800 GT (driver version 181.20) that has performance problems when I use FBOs (see attached test case, modified from osgviewer.cpp). My draw times jump from about 7 milliseconds to 14, and my GPU times jump from less than 1ms to 7ms. The problem goes away when I switch from Multiple display performance mode to Single display performance mode in the NVIDIA Control Panel, so this looks like a driver bug, but I was wondering if anyone was aware of this problem and any ways around it (I didn't find any discussion of such a bug via google)? I'm running on Windows MSVC 2005 using OSG svn rev 10273. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com gen2pass.cpp Description: gen2pass.cpp ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multidisplay FBO performance
Wojciech Lewandowski wrote on Tuesday, June 09, 2009 11:25 AM: I have similar setup. 8800 GTS Windows XP 32 bit driver version. Drivers 185.85. Default (undefined USE_FBO) osgviewer cow.osg on two 1280x1024 screens runs at 600 hz. When graph stats are turned on (second 's' keypress) framerate drops to 60-70 hz. When running your modified osgviewer cow.osg I see empty blue screen (I assume its ok as cow is drawn to FBO). With USE_FBO results vary depending on multithreading mode: singlethreaded is most consitent - 300-400 hz. Other modes sometimes run at 700 hz and drop to 60 hz for a second or two to get back to 700 and drop again after few more seconds. Sometimes its stable at 700 sometimes it starts at 60+ hz. All tests done only with Hz counter. Invoking graph stats usually drops framerate below 100hz. When 'Single display performance' invoked osgviewer runs on one screen in XP. I suppose you are on Vista because I saw drivers work on both screeens there. I forgot to mention that I am running with OSG_SCREEN=0 so that it only displays on one screen, even with 'Multiple display performance' set. I've only been looking at the FRAME_RATE stats. I am using Windows XP Pro 32bit. It isn't 100% clear from your description, but it doesn't sound like you're having the same behavior I am; most of the time, I am getting 14 millisecond draw times, which still gets me 60Hz, but is nowhere near 300 or 700Hz (though I a have vsync on, so I won't see those numbers directly). I didn't think to check before, but SingleThreaded does seem to help some (my test case's draw time goes from 14 to 9 milliseconds). I'll give the 185.85 driver a shot. Thanks for the help! - Original Message - From: Thrall, Bryan bryan.thr...@flightsafety.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, June 09, 2009 5:02 PM Subject: [osg-users] Multidisplay FBO performance I have a multiple display system with an NVIDIA 8800 GT (driver version 181.20) that has performance problems when I use FBOs (see attached test case, modified from osgviewer.cpp). My draw times jump from about 7 milliseconds to 14, and my GPU times jump from less than 1ms to 7ms. The problem goes away when I switch from Multiple display performance mode to Single display performance mode in the NVIDIA Control Panel, so this looks like a driver bug, but I was wondering if anyone was aware of this problem and any ways around it (I didn't find any discussion of such a bug via google)? I'm running on Windows MSVC 2005 using OSG svn rev 10273. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ReaderWriter options for paged data
Max Bandazian wrote on Monday, June 08, 2009 12:09 PM: Hi, I have some paged data with DDS textures, which require the ReaderWriter's dds_flip option to be off, and some other data also with DDS textures that require dds_flip to be on. Here's the problem: The data can be loaded in any order, and if I e.g. - set dds_flip off - load the paged file - set dds_flip on - load the non-paged files, the paged data has its textures upside down, since they're not loaded until after dds_flip is back on. Is there any way to associate some ReaderWriter options with a specific file, or do something similar to allow paged data to load with different options than the global settings? Thanks, Max Bandazian You can attach an osgDB::Options object with the appropriate options string to the PagedLOD that loads the textures (see osg::PagedLOD::setDatabaseOptions()). -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] per-facet normals for flat facets
Butler, Lee Mr CIV USA USAMC wrote on Monday, June 01, 2009 1:55 PM:
I'm looking for ways to efficiently store/display geometry with flat
facets. That is to say, I want all creases (no interpolated
normals).
I'm reading some hefty geometry (10-20M polys) for display (Currently
in
OBJ format). There are only hundreds of unique normals. The OBJ
loader
tristrips everything and computes per-vertex normals.
Since I'm bumping up against the memory address limit on 32bit
machines
when using this geometry, I'd *really* like to recoup the storage for
all those (redundant) normals. I think using short ints for 'normal
indexes' instead of per-vertex normals would buy me a fair bit of
space.
Can anyone offer any pointers/guidance?
Lee
Hi Lee,
I don't know anything about the OBJ loader except what 'osgconv --format
obj' tells me. Do the 'noTesselateLargePolygons' or 'noTriStripPolygons'
help?
$ osgconv --format obj
Plugin osgPlugins-2.9.5/osgdb_obj.dll
{
ReaderWriter : Wavefront OBJ Reader
{
features : readNode writeObject writeNode
extensions : .objAlias Wavefront OBJ
format
options: AMBIENT=unit Set texture unit for
ambient texture
options: BUMP=unit Set texture unit for
bumpmap texture
options: DIFFUSE=unit Set texture unit for
diffuse texture
options: DISPLACEMENT=unit Set texture unit for
displacement texture
options: OPACITY=unit Set texture unit for
opacity/dissolve texture
options: REFLECTION=unit Set texture unit for
reflection texture
options: SPECULAR=unit Set texture unit for
specular texture
options: SPECULAR_EXPONENT=unitSet texture unit for
specular exponent texture
options: noRotation Do not do the default
rotate about X axis
options: noTesselateLargePolygonsDo not do the default
tesselation of large polygons
options: noTriStripPolygons Do not do the default
tri stripping of polygons
}
}
HTH,
--
Bryan Thrall
FlightSafety International
bryan.thr...@flightsafety.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Access vertices and faces after load the model
Paul Melis wrote on Friday, May 29, 2009 9:55 AM: Thrall, Bryan wrote: Paul Martz wrote on Thursday, May 28, 2009 4:50 PM: You use a NodeVisitor to walk your scene graph and look for Geodes, then iterate over the Drawables that are attached to the Geodes, using dynamic_cast to access the Drawable as a Geometry. Even better, I notice osg::Drawable has asGeometry(), which is cheaper than dynamic_cast :) Wow, I wasn't expecting the difference to be this large, as virtual function calls aren't completely free either: ... 16:52|p...@tabu:~ ./t 1 asGeometry(): 1.181 ms dynamic_cast(): 3.945 ms 16:52|p...@tabu:~ g++ -O3 -o t t.cpp -I ~/osg2.8/include/ -L ~/osg2.8/lib/ -losg -losgDB 16:52|p...@tabu:~ ./t 1 asGeometry(): 0.839 ms dynamic_cast(): 3.611 ms 16:52|p...@tabu:~ That's even more impressive than I was expecting! -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
