[osg-users] Using osg::Camera without a view
Hiya, This is a bit of a strange question. I want to use an osg::Camera purely as a shell object to use some of its handy methods (ie. all the setters and getters for the various view/model/projection matrices). Can I do this without setting up a viewer or invoking any OpenGL code (assume inactive context)? If I do something like: // note there's no osgViewer here osg::Camera cam; cam.setViewport(...); cam.setViewMatrixAsLookAt(...); cam.setProjectionMatrixAsPerspective(...); osg::Matrixd viewMatrix = cam.getViewMatrix(); Will this 'just work'? Or is there internal stuff in osg::Camera that needs the object to belong to a viewer / have a proper view/context/etc setup? Preet ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osg::Camera without a view
Hi Preet, On 15 June 2013 07:44, Preet prismatic.proj...@gmail.com wrote: Will this 'just work'? Or is there internal stuff in osg::Camera that needs the object to belong to a viewer / have a proper view/context/etc setup? I can't see any reason why it wouldn't work. The osg::Camera is essentially just a data container, it doesn't have any active role in rendering, it just tells the rendering backend what it needs to do. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] Refraction Map issue: isn't visible...
Hi Dario, it should work with the latest from trunk I think. It's been a while since I used osgOcean but somehow it worked for me. Just fyi Nick On Fri, Jun 14, 2013 at 5:43 PM, Dario Minieri para...@cheapnet.it wrote: Hi, I'm using still now OsgOcean rev 208. I'm update to the last rev 258. Refraction seems don't work. I have a scene with refraction enabled, withe rev208 I can see the refraction, not with the rev258. Someone has reported this issue? I'm looking now around the refracition code, but is a bit expansive... Thank you! Cheers, Dario -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54620#54620 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Deprecating vertex indices in osg::Geometry
Hi. I'm not sure I follow the discussion, since each post is starting to become a separate article, but I'll try to tell what I think. I don't know the policy on OSG ABI, but if it's to keep ABI compatible between some releases, I would: * add compile flag to select between old and new Geometry (defaults to old one); * warn during compile time and during running (into the log) that using the old Geometry is deprecated and will be removed in the following stable release; * warn in changelog about the coming ABI breakage; If the policy is only to keep API compatibility with some minor changes like obsoleting unused functions, then Geometry could be removed. 2013/6/15 Robert Osfield robert.osfi...@gmail.com Hi Mattias et. al, On 14 June 2013 14:23, Mathias Fröhlich mathias.froehl...@gmx.net wrote: I really like the idea of GeometryDeprecated. It takes somehow more work to make this happen for users. But at very first it's just about changing a single datatype. Once it compiles with osg::Geometry again you know that you will nowhere have a slow path geometry anymore. You do not need to rely on your test coverage and an exception then. I know, this is against what you usually do with your api. My clean up work today has focused on sliming down osg::ArrayDispatchers and as a knock on effect implementing GeometryDeprecated has become a bit more complicated as it'll need to take on more of the work that ArrayDispatchers used to handle. I don't think it's right for us to bloat the core OSG just to maintain deprecated functionality so my current inclination is to perhaps even go further and not provide GeometryDeprecated at all. I'm currently toying with the idea of leaving the deprecated slow path methods in osg::Geometry and have flag that gets set to declare this osg::Geometry in invalid condition that can't be rendered or handled in any osg::Geometry processing, to make this osg::Geometry usable you'd then call an optimize method that converts all the indices and per primitive usage into OpenGL fast path compliant usage. My current implementation has the valid fast path version of this osg::Geometry nested within the invalid one and used in it's place when rendering, but this feels a bit cludgy and potentially inefficient when it comes to updates. The awkwardness with this nested osg::Geometry is why I'm starting to wonder if just labelling these problem osg::Geometry as invalid and let them be ignored unless the uses runs the optimize method. For the .osg, .ive loaders and new serilizers and thinking that by default we could automatically run the optimizer on the any problem osg::Geometry that have been loaded. If we really start to optimize geometries under the hood, when would you do this then? You cannot rely on anything in osgDB since you have to account for in application generated geometries. The only non concurrent opportunity is the update stage so far. Ok, let's assume that happens there. But then we at least have *huge* geometries. Processing them with this kind of optimization to get rid of the indices and that can take a long time. It can, so I'm inclined to push this back to user and do a one time convert after they have created the osg::Geometry. When could possible have a contains invalid osg::Geometry flag in the whole scene graph so that the update traversal knows it needs to hunt down and convert them, this does add complexity though. The other alternative might be to have a linked list of invalid osg::Geometry that need to be dealt with. Having this invalid/deprecated osg::Geometry be updated each frame would be very costly, but then they are any way. What we really want users to do is migrate away from ever creating these bad osg::Geometry in the first place, so having to jump through an extra hoop or two to make it explicit about what is happening might be the best way, even if it does mean that end users can't just recompile and run with the latest OSG and expect everything including there old deprecated usage to still work. Offically array Indices and BIND_PER_PRIMTIVE have been deprecated for several releases, every time the topic is mentioned I try to persuade users to use fast paths. The inline docs have long been clear that they are deprecated so perhaps I needn't be so accommodating. We experience this as of today with non fast path geometries where the driver is doing this work under the hood. And in contrast to osg these drivers have a long histroy of optimizing this code paths and are well optimized. OpenGL drivers have been better at replicating the glBegin/glEnd than the OSG equivalent found in the osg::GLBeginEndAdapter, as much as I tried to optimize the later I could never get the same performance as what the OpenGL driver was doing. By contrast fast path osg::Geometry are relatively easy to just push out to OpenGL without a big CPU overhead. Also update is
Re: [osg-users] Deprecating vertex indices in osg::Geometry
HI Michael, On 15 June 2013 15:59, michael kapelko korn...@gmail.com wrote: I'm not sure I follow the discussion, since each post is starting to become a separate article, but I'll try to tell what I think. The thread might be a little meandering, but it's still roughly on topic. The meandering is partly down to be testing out different API and implementation approaches. I don't know the policy on OSG ABI, but if it's to keep ABI compatible between some releases, I would: * add compile flag to select between old and new Geometry (defaults to old one); * warn during compile time and during running (into the log) that using the old Geometry is deprecated and will be removed in the following stable release; * warn in changelog about the coming ABI breakage; If the policy is only to keep API compatibility with some minor changes like obsoleting unused functions, then Geometry could be removed. The approach we've taken has been for patch releases within a stable release set to remain binary compatible, i.e. 3.0.0 is binary compatible with 3.0.1. For developer series I don't attempt to retain binary compatible, and don't expect to retain binary compatibility. In general I do try and maintain the bulk of the API so the majority of OSG users can move between developer and close stable releases without too much effort. My current expectation is that the new cleaned up, fast path only osg::Geometry will not have all the methods and data structures that OSG-3.0.x osg::Geometry had but for most users will just compile and work as before. Those using slow path API's such as array indices and BIND_PER_PRIMITIVE will have to do something extra, either porting away from these long deprecated features, or adding a call to like geometry-fixDeprecatedData(); I don't know yet whether we should make these deprecated API's #ifdef'd out or not yet, if we do we'd want to maintain the ABI so use of inline functions may be the way to go. I'm getting close to checking in my new cleaned up osg::Geometry, once I do hopefully most users will be able to say of that nice cleanup and all I had to do is recompile, but with others using the old deprecated functionality we'll need to help them port across/refine what the OSG provides in terms of fallback. Once I have the cleanup version of osg::Geometry checked in there will still be work within the OSG to continue moving across to using just the non deprecated API, for this I'll need assistance from the community. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] Refraction Map issue: isn't visible...
maybe you post a code snippet of your settings if someone can look at Nick On Sat, Jun 15, 2013 at 7:19 PM, Dario Minieri para...@cheapnet.it wrote: Hi, Hummmmaybe is my fault in somewhat, but I make two snapshot of oceanExample and the refraction seems to me don't works. I've tested others my scenes and the result is the same. snap_no_refraction1.jpg shows the example scene without refraction and, in effect, apart the rev208 artifacts, the refraction is not visible. snap_with_refraction1.jpg shows the example scene with refraction, and, the rev 258 is the same as above (no refraction in any cases), rev 208 shows the refraction of the island above water dynamic line. There are some parameters or others changes to make which are changed and I forgot? Thank you! Cheers, Dario -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54633#54633 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
