[osg-users] Deprecating vertex indices in osg::Geometry
Hi All, One of the changes I've discussed before, but as yet no made, is to simplify osg::Geometry so that it drops the index arrays that you can currently associated for vertex, normal, colour, texcoord arrays. These index arrays aren't supported by OpenGL, instead have to be emulated by breaking the primitive data up into small chunks and sending the vertex data and primitive data in small batches. This is very inefficient, so what having separate vertex indicies might seem like a good way of reducing vertex data overhead by sharing more it causes a big CPU overhead and results in lower performance. While there are clear warnings in the osg::Geometry header that this feature is deprecated and forces and OpenGL slow path I know it still gets used on occasion - against best practice advice. What I'd like now to do is drop the index arrays from osg::Geometry, and provide a GeometryDeprecated class for the those who need backwards compatibility. Potentially this GeometryDeprecated class could go in the core osg library, but I'm tempted to move it out into one of the optional NodeKits to reduce the size of the core osg library. To be clear OpenGL indexed primitives will still be fully support by osg::Geometry - DrawElement* has always been available and will remain, it's the long been the preferred way to pass your primitive data to OpenGL. Another step in making these changes that I'm considering is moving the normalize parameter from Geometry::ArrayData into osg::Array, with this change ArrayData ceases to have a role and can be removed further simplifying osg::Geometry. Thoughts? Robert. ___ 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
I have now started looking into what changes would be required to osg::Geometry and have decided to make a copy of Geometry called GoemetryNew and cut this down to see how easy it will be clean this class up and what the knock on effects might be. Now I have dived in and begun the process one what is clear is just how much the implementation of Geometry.cpp was complicated by the support for indices - the size of GeometryNew.cpp text file is now 1982 bytes vs 2763 for the old Geometry.cpp. Getting rid of indices will reduce footprint and also will make the code faster as they will be less checks to see if indices are there and need something special doing for them. Another element that jumps out as out of step with modern OpenGL is support for PER_PRIMITIVE binding of arrays - this still forces OpenGL slow paths and again complicates the code. I believe that osg::Geometry really should just support fast paths so as part of the cleanup it would reasonable to drop this from GeometryNew.cpp as well. I will tackle the indices first though. My current action plan is to get GeometryNew.cpp to build and run with the osggeometry example, then look for feedback from the community. If things look viable then the next step will be rename GeometryNew.cpp to Geometry.cpp and renamed the existing Geometry.cpp to GeometryDeprecated.cpp. This step will require some games on the serialization front to return backwards compatibility. Another area of change would be looking at Geometry::ArrayData - this currently contains array, indices, binding and normalize variables. My first step is to simply remove indices, but I'm thinking that binding and normalize might both be suitable for moving into osg::Array and for ArrayData to be removed entirely. Thoughts? Robert. ___ 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
On 4 June 2013 09:42, Robert Osfield robert.osfi...@gmail.com wrote: My current action plan is to get GeometryNew.cpp to build and run with the osggeometry example I have now got my quick clean up of Geometry as GeometryNew class with osgeometry compiling and running correctly. My GeometryNew class removes support for vertex indices. My next step is to look at BIND_PER_PRIMITIVE. While vertex indices aren't actually used in the core OSG BIND_PER_PRIMITIVE is quite widely used in the examples. They really shouldn't be though as it means that they are all forces slow paths in osg::Geometry. I don't know yet whether to check in GeometryNew, or whether to wait till I've done enough work to renamed the old Geometry to GeometryDeprecated and rename GeometryNew to Geometry. I'm currently inclined to do this work in stages and check in GeometryNew even if it's just a temporary class name. Again I welcome feedback 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] Deprecating vertex indices in osg::Geometry
Robert, I think it's better to check it in.. Others would have the opportunity to participate or evely siltently read the code and learn. Maybe there aer others out there reading changes and try to learn as I do it usually ( If time permits). Regards, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54420#54420 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Saving a screenshot as a scaled up image
Hi, Have you looked at osgPoster? thanks, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54421#54421 ___ 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
On 4 June 2013 10:21, Torben Dannhauer tor...@dannhauer.info wrote: I think it's better to check it in.. Others would have the opportunity to participate or evely siltently read the code and learn. Maybe there aer others out there reading changes and try to learn as I do it usually ( If time permits). GeometryNew is now checked in, along with osggeometry that has been ported to it - simply a name change as osggeometry.cpp was already clean w.r.t using only fast paths. GeometryNew doesn't have any array indices buit still supports BIND_PER_PRIMITIVE, so this will be my next bit of work. I've been looking at other OSG examples and find out that several use BIND_PER_PRIMITIVE, ouch... slow path examples! These are: osganimate/osganimate.cpp osgdelaunay/osgdelaunay.cpp osgimpostor/osgimpostor.cpp osgocclusionquery/osgocclusionquery.cpp osgoscdevice/osgoscdevice.cpp osgphotoalbum/osgphotoalbum.cpp osgpick/osgpick.cpp osgsharedarray/osgsharedarray.cpp I will work through these removing the deprecated usage to make it possible to port them over to the evolving GeometryNew. For most users I'm hoping that they will have already been create osg::Geometry that is all clean and using fast paths, if that's the case then they won't need to make any changes in their applications - a simple rebuild will be sufficient. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Question about OSG for Android
Dear Ladies and Gentlemen, I am currently working on developing a visualization tool using OpenSceneGraph. I am supposed to develop a branch for the tool to work on Android. I am having some problems and my experience with OSG cannot really help me pass it. In few Words - - My tool should have multiple views of the displayed object. Something like CAD software or Maya (where you basically have 4 views, one orthogonal view and 3 top, front and side views). - -I easily managed to do that on Widows using Composite Viewer displaying multiple Views. On Android I used the example provided of GLES1. In the native code. OsgViewer is used and it is setup in the window by using *setUpViewerAsEmbeddedInWindow() *. - - I am trying to use different function to setup the view for the windows but It does not seem to work, I am always getting this error *(View::setUpViewAcrossAllScreens() : Error, no WindowSystemInterface available, cannot create windows.*). - - What do you think the problem here? for Android it is better to use One *CompositeViewer* as the render object for the EGLView class in Java? or is it better to make different EGL instances with different normal *Viewer?* Thanks in advance for your help, Best Regards, Mahmoud Aly * * ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question about OSG for Android
HI Mohmoud, I haven't programmed on Android yet, but as CompositeViewer can be made to work with a single GraphicsContext I see no reason why you can't just create a GraphicsWindowEmbedded and assign this to each of your View's Camera, with a separate Viewport selecting the part of the window you want to use. Robert. On 4 June 2013 11:23, Mahmoud Hossam maxc1...@gmail.com wrote: Dear Ladies and Gentlemen, I am currently working on developing a visualization tool using OpenSceneGraph. I am supposed to develop a branch for the tool to work on Android. I am having some problems and my experience with OSG cannot really help me pass it. In few Words - - My tool should have multiple views of the displayed object. Something like CAD software or Maya (where you basically have 4 views, one orthogonal view and 3 top, front and side views). - -I easily managed to do that on Widows using Composite Viewer displaying multiple Views. On Android I used the example provided of GLES1. In the native code. OsgViewer is used and it is setup in the window by using setUpViewerAsEmbeddedInWindow() . - - I am trying to use different function to setup the view for the windows but It does not seem to work, I am always getting this error (View::setUpViewAcrossAllScreens() : Error, no WindowSystemInterface available, cannot create windows.). - - What do you think the problem here? for Android it is better to use One CompositeViewer as the render object for the EGLView class in Java? or is it better to make different EGL instances with different normal Viewer? Thanks in advance for your help, Best Regards, Mahmoud Aly ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Deprecating vertex indices in osg::Geometry
Hi Robert, On Tuesday, June 04, 2013 09:42:10 Robert Osfield wrote: Thoughts? Great idea! I see that the GeometryDeprecated is still needed. ... that means we will need this at least. The begin/end emulation code could then probably move to wherever you move the GeometryDeprecated class. What about the plugins? Do all of them consistently use the fast path? May be this is also an opportunity to throw out the deprecated dlists? Also to get good 'fast path' performance, handlling of primitive restart would be good. I know there were discussions about that. But was there a final outcome how you want to have this implemented? Greetings Mathias ___ 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 Mathias, On 4 June 2013 13:53, Mathias Fröhlich mathias.froehl...@gmx.net wrote: I see that the GeometryDeprecated is still needed. ... that means we will need this at least. I don't think it'll be too difficult to maintain, and it'll be really useful to old Geometry held in the existing .osg/.ive files. The begin/end emulation code could then probably move to wherever you move the GeometryDeprecated class. Yes! :-) What about the plugins? Do all of them consistently use the fast path? We'll have review them one by one. Most should be using fast paths, ones that aren't we'll need to port across to using GeometryDeprecated if it isn't easy to port them across to the new cleaned up osg::Geometry. May be this is also an opportunity to throw out the deprecated dlists? I don't reason a need to drop display lists in osg::Geometry, at least at this point. Display lists are rather orthogonal to the rest of the API. One thing the clean up will mean is a simpler internal implementation that will have a lower CPU overhead so the cost on non display listing will be lower so more models that presently work best with display lists will now be better without. I do still expect display lists to work best for some models and OpenGL drivers though. Also to get good 'fast path' performance, handlling of primitive restart would be good. I know there were discussions about that. But was there a final outcome how you want to have this implemented? Ooo I'm a bit cold on primitive restart, I vaguely recall some discussion previous about it but it's long enough ago for me to not have a clear idea. In general I'd say with a clean up osg::Geometry will be in better place to look at implementing the new OpenGL features, these will be focused on the new Geometry implementation with GeometryDepercated being specifically for backwards compatible slow path usage without attempting to update it to latest OpenGL features. This approach will free us from some of the sticky bits of implementation - the glBegin/glEnd emulation is an example of this. Robert. ___ 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, On Tuesday, June 04, 2013 14:12:21 Robert Osfield wrote: May be this is also an opportunity to throw out the deprecated dlists? I don't reason a need to drop display lists in osg::Geometry, at least at this point. Display lists are rather orthogonal to the rest of the API. One thing the clean up will mean is a simpler internal implementation that will have a lower CPU overhead so the cost on non display listing will be lower so more models that presently work best with display lists will now be better without. I do still expect display lists to work best for some models and OpenGL drivers though. This is definitely orthogonal. The reason is more that users already need to change their geomertry for this particular change. So may be it's a good time to clean up a little more than to annoy these people again in say two years with some more changes in this area. But that's just a thought ... Also to get good 'fast path' performance, handlling of primitive restart would be good. I know there were discussions about that. But was there a final outcome how you want to have this implemented? Ooo I'm a bit cold on primitive restart, I vaguely recall some discussion previous about it but it's long enough ago for me to not have a clear idea. In general I'd say with a clean up osg::Geometry will be in better place to look at implementing the new OpenGL features, these will be focused on the new Geometry implementation with GeometryDepercated being specifically for backwards compatible slow path usage without attempting to update it to latest OpenGL features. This approach will free us from some of the sticky bits of implementation - the glBegin/glEnd emulation is an example of this. Well, primitive restart allows you to merge a lot of indexed primitive sets into a single one for triangle strips for example. Without you need to emit a lot of extra draws for each strip. That means this takes a whole lot of cpu cycles to do the draw setup on the gpu for a few triangles in the strip. this in turn make strips basically unusable if you are draw bound. Or you will get draw bound because of that. Primitive restart allows you to specify a 'magic index' that can be placed in the index array to signal the GPU that a new strip begins. By that you get back huger bunches of draws scheduled with a single OpenGL draw call doing the GPU setup just this single time. Conceptually this is an OpenGL state like any other StateAttribute you already implemented. So the easiest would be to add an other StateAttribute for this. The bad thing is that you cannot rely on this to be present as an OpenGL extension but requires the geometry to be built in a different way. So the additional code path to do is more or less intrusive. The good thing is that a whole lot of gpu's do handle primitive restart. May be an optimizer pass that spits primitive restart draw element calls could be useful for this. Anyway, that's also kind of orthogonal. But once people need to change their geometries for this renewed Geometry class it might be also a natural point for somebody using osg to move to restarted strips if this is possible. Greetings Mathias ___ 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 Robert, Would you consider changing BIND_PER_PRIMITIVE code to do some kind of internal conversion to fast path rendering, such as expanding the arrays by 3x (duplicating the color or normal for each vertex) so that it can use the per-vertex rendering path? I have certainly written code where I wanted per-face coloring or sharp edged shading (same normal across the face) and PER_PRIMITIVE captures my intent better than using PER_VERTEX and having to duplicate the colors/normals. It's not a big deal, but having the concept handled by osg::Geometry is more convenient than handling it in client code --- as you've noted, even in the examples PER_PRIMITIVE is used quite a bit. - Peter On 6/4/2013 5:14 AM, Robert Osfield wrote: On 4 June 2013 09:42, Robert Osfield robert.osfi...@gmail.com wrote: My current action plan is to get GeometryNew.cpp to build and run with the osggeometry example I have now got my quick clean up of Geometry as GeometryNew class with osgeometry compiling and running correctly. My GeometryNew class removes support for vertex indices. My next step is to look at BIND_PER_PRIMITIVE. While vertex indices aren't actually used in the core OSG BIND_PER_PRIMITIVE is quite widely used in the examples. They really shouldn't be though as it means that they are all forces slow paths in osg::Geometry. I don't know yet whether to check in GeometryNew, or whether to wait till I've done enough work to renamed the old Geometry to GeometryDeprecated and rename GeometryNew to Geometry. I'm currently inclined to do this work in stages and check in GeometryNew even if it's just a temporary class name. Again I welcome feedback from the community. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] File comment blocks conflict with OSGPL licensing, geo plugin
Hi David, On 22 May 2013 20:55, Robert Osfield robert.osfi...@gmail.com wrote: I'm inclined to think it's safe to remove it as it's for a defunct product and likely to mostly out of use now. As there was no response in support for maintaining the .geo plugin, and Carbon Graphics has long been defunct I couldn't see a reason to keep it around. I have now removed the geo plugin from svn/trunk, so it'll not be part of the the next 3.1.8 dev release. Cheers, Robert. ___ 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 Peter, On 4 June 2013 14:29, Peter Amstutz peter.amst...@tseboston.com wrote: Would you consider changing BIND_PER_PRIMITIVE code to do some kind of internal conversion to fast path rendering, such as expanding the arrays by 3x (duplicating the color or normal for each vertex) so that it can use the per-vertex rendering path? That is what the OSG has been doing since 3.0.x but this type of emulation is very slow. While it might be convenient for end users It's bad for a scene graph to hiding the complexity to such an extent that you get huge slow down with seemingly Innocent usage. I much prefer making efficient use of OpenGL the default, and dropping off efficient fast paths something you have to try hard to do, rather than something you can do without even realizing. Going forward there are advanced features of OpenGL that really build upon the that vertex arrays can be accessed and how primitive data is used that doesn't fit well with this old functionality. I have certainly written code where I wanted per-face coloring or sharp edged shading (same normal across the face) and PER_PRIMITIVE captures my intent better than using PER_VERTEX and having to duplicate the colors/normals. It's not a big deal, but having the concept handled by osg::Geometry is more convenient than handling it in client code --- as you've noted, even in the examples PER_PRIMITIVE is used quite a bit. I understand the convenience angle, but as it hides a multitude of sins I don't believe it's a good practice. Perhaps the best way to deal with this to to help a osg::Geometry builder class that can help users create the data they want in a convenient form. In the short term you could simply use GeometryDeprecated. Having a converter from GeometryDeprecated to new cleaned up Geometry will be relatively straight forward and might be another approach. I believe that a fast path only osg::Geometry is worthy enough goal to explicitly drop all slow path support, so it only supports what modern OpenGL can support with no clever emulation being hidden behind the scenes. This does mean the convenience of things like vertex indices and BIND_PER_PRIMITIVE have to be dropped, to deal with this I don't think new osg::Geometry should bend to accomodate, rather we should seek out ways of making it more convenient to create osg::Geometry - I call upon the community to make suggestions about help classes. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Fwd: Question about OSG for Android
Hi, I tried changing this method [code]_viewer-setUpViewerAsEmbeddedInWindow(x, y, width, height); [/code] by creating my own GraphicsWindowEmbedded and assigning it to the camera [code]osgViewer::GraphicsWindowEmbedded* _gwe = new osgViewer::GraphicsWindowEmbedded(x,y,width,height); osg::Camera* _camera = new osg::Camera(); _camera-setGraphicsContext(_gwe); _viewer-setCamera(_camera);[/code] and i used it just with a single Viewer not a Composite one but it is still doesnot seem to work. Thank you for your replay! Cheers, Mahmoud ___ 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 Robert, This is totally reasonable and on balance I agree with your reasoning. I thought the feature deserved a little discussion before being sent quietly into the night :-) On 6/4/2013 9:44 AM, Robert Osfield wrote: I believe that a fast path only osg::Geometry is worthy enough goal to explicitly drop all slow path support, so it only supports what modern OpenGL can support with no clever emulation being hidden behind the scenes. This does mean the convenience of things like vertex indices and BIND_PER_PRIMITIVE have to be dropped, to deal with this I don't think new osg::Geometry should bend to accomodate, rather we should seek out ways of making it more convenient to create osg::Geometry - I call upon the community to make suggestions about help classes. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ 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 Peter, On 4 June 2013 15:34, Peter Amstutz peter.amst...@tseboston.com wrote: This is totally reasonable and on balance I agree with your reasoning. I thought the feature deserved a little discussion before being sent quietly into the night :-) ;-) The reason for me to raise this topic is specifically to get full spectrum of opinions and issues that might arise. While as project lead it's my job to steer the over course that the code takes but if I head off in direction that doesn't take the community with it then I'm damaging the project, so expect and want users to jump and down in discontent to make sure that any new decisions are sound and well justified. Robert. ___ 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 All,
I have now taken the next step and added the following methods to osg::Array:
/** Specify whether the array data should be normalized by OpenGL.*/
void setNormalize(bool normalize) { _normalize = normalize; }
/** Get whether the array data should be normalized by OpenGL.*/
bool getNormalize() const { return _normalize; }
/** Set hint to ask that the array data is passed via integer
or double, or normal setVertexAttribPointer function.*/
void setPreserveDataType(bool preserve) { _preserveDataType =
preserve; }
/** Get hint to ask that the array data is passed via integer
or double, or normal setVertexAttribPointer function.*/
bool getPreserveDataType() const { return _preserveDataType; }
/** Set the rate at which generic vertex attributes advance
during instanced rendering. Uses the glVertexAttribDivisor feature of
OpenGL 4.0*/
void setAttribDivisor(GLuint divisor) { _attribDivisor = divisor; }
/** Get the rate at which generic vertex attributes advance
during instanced rendering.*/
GLuint getAttribDivisor() const { return _attribDivisor; }
enum Binding
{
BIND_OFF=0,
BIND_OVERALL,
BIND_PER_PRIMITIVE_SET,
BIND_PER_VERTEX
};
/** Specify how this array should be passed to OpenGL.*/
void setBinding(Binding binding) { _binding = binding; }
/** Get how this array should be passed to OpenGL.*/
Binding getBinding() const { return _binding; }
At present all of them doing nothing at all apart from sitting there
looking pretty. The PreserveDataType and AttribDivisor are entirely
new and are intended to support new extensions being added to the OSG
- but their implementation will have to wait till the GeometryNew
refactor is further down the road.
The Normalize and Binding map directly to what has been available in
osg::Geometry::ArrayData's normalize and binding parameters. The
binding we've typically set via Geometry::setNormalBinding() etc.
which we could easily remap internally to array-setBinding(..), but
it will of course require one to call setNormalBinding() after
setNormalArray(..) otherwise the setting would be lost. Alternatively
we just drop backwards compatibility and force uses to set the binding
directly on the array.
Providing backwards compatibility for normalize will more awkward as
custom normalize settings would require a direct setting to ArrayData,
however, I'm inclined to think dropping this element of backwards
compatibility won't effect too many users as I expect most users not
to be applying anything other than defaults.
The naming of Binding is something I'm note yet sure of, with the
introduction of AttribDivisor the binding becomes a bit less clearly
defined as well. Not sure what to make of this yet...
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Modern OSG vs. OSG 2.8.5; also a question about word splitting in osgText
Thanks Robert. I'll spend some time getting the newest OSG working here, and then try applying my patch, and submit it for your perusal. Eric On Mon, Jun 3, 2013 at 7:26 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Eric, On 3 June 2013 11:42, Eric Sokolowsky esok@gmail.com wrote: I have been an active contributor to OSG in the past but have not kept up with recent developments. I have an application that uses OSG 2.8.5 mostly unmodified except for one patch that changes the way osgText breaks up words. I am wondering how easy it is generally to port programs forward from OSG 2.8.5 to the current release (appears to be 3.0.1, at least that is what is available by default in Fedora 17). Mostly it should be just a re-compile. The main changes were additions that won't require changes to most applications that use the OSG. I am of course willing to submit the changes I made to the word splitting in OSG, but how accepted will that be to the community? With the default word splitting, I was seeing things like: Large numbers split in the middle: 1,000\n,000,000 (The \n is where the line split occurred) Punctuation shown at the beginning of the next line instead of at the end of a line: This is the end\n. This is another sentence. Date/time split in strange places: 15:27\n:12 My new rules make the only splitting points at spaces and at hyphens (leaving the hyphen at the end of the line). If others depend on the current line-splitting method, I can create a patch that would allow the user to choose which method to use. It's hard to know without seeing the submission, feel free to submit and I can then have a think. We also have a TextNode implementation in the works that allows custom control of layout among other elements so it might be a good place for the custom work. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Deprecating vertex indices in osg::Geometry
Hi,
Just a coment. Deprecate inmediate mode is also and advantage w.r.t. mobile
devices. OpenGL_ES does not implement inmediate mode since its first
version, and display lists are no supported since OpenGL_ES 1.1. So it will
be good for those starting with ES and OpenSceneGraph.
Cheers.
2013/6/4 Robert Osfield robert.osfi...@gmail.com
Hi All,
I have now taken the next step and added the following methods to
osg::Array:
/** Specify whether the array data should be normalized by
OpenGL.*/
void setNormalize(bool normalize) { _normalize = normalize; }
/** Get whether the array data should be normalized by OpenGL.*/
bool getNormalize() const { return _normalize; }
/** Set hint to ask that the array data is passed via integer
or double, or normal setVertexAttribPointer function.*/
void setPreserveDataType(bool preserve) { _preserveDataType =
preserve; }
/** Get hint to ask that the array data is passed via integer
or double, or normal setVertexAttribPointer function.*/
bool getPreserveDataType() const { return _preserveDataType; }
/** Set the rate at which generic vertex attributes advance
during instanced rendering. Uses the glVertexAttribDivisor feature of
OpenGL 4.0*/
void setAttribDivisor(GLuint divisor) { _attribDivisor = divisor; }
/** Get the rate at which generic vertex attributes advance
during instanced rendering.*/
GLuint getAttribDivisor() const { return _attribDivisor; }
enum Binding
{
BIND_OFF=0,
BIND_OVERALL,
BIND_PER_PRIMITIVE_SET,
BIND_PER_VERTEX
};
/** Specify how this array should be passed to OpenGL.*/
void setBinding(Binding binding) { _binding = binding; }
/** Get how this array should be passed to OpenGL.*/
Binding getBinding() const { return _binding; }
At present all of them doing nothing at all apart from sitting there
looking pretty. The PreserveDataType and AttribDivisor are entirely
new and are intended to support new extensions being added to the OSG
- but their implementation will have to wait till the GeometryNew
refactor is further down the road.
The Normalize and Binding map directly to what has been available in
osg::Geometry::ArrayData's normalize and binding parameters. The
binding we've typically set via Geometry::setNormalBinding() etc.
which we could easily remap internally to array-setBinding(..), but
it will of course require one to call setNormalBinding() after
setNormalArray(..) otherwise the setting would be lost. Alternatively
we just drop backwards compatibility and force uses to set the binding
directly on the array.
Providing backwards compatibility for normalize will more awkward as
custom normalize settings would require a direct setting to ArrayData,
however, I'm inclined to think dropping this element of backwards
compatibility won't effect too many users as I expect most users not
to be applying anything other than defaults.
The naming of Binding is something I'm note yet sure of, with the
introduction of AttribDivisor the binding becomes a bit less clearly
defined as well. Not sure what to make of this yet...
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Jordi Torres
___
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
On 4 June 2013 17:56, Jordi Torres jtorresfa...@gmail.com wrote: Just a coment. Deprecate inmediate mode is also and advantage w.r.t. mobile devices. OpenGL_ES does not implement inmediate mode since its first version, and display lists are no supported since OpenGL_ES 1.1. So it will be good for those starting with ES and OpenSceneGraph. Indeed. The cleaned up Geometry will also me smaller and faster too, certainly a help for mobile devices. Robert. ___ 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 Robert, These changes sound good. I'm all for cleaning up the Geometry class. You mentioned implementing some sort of backwards compatibility for the serialization plugins. Does that mean existing osg files (osg, ive, osgb, etc...) that use indices will automatically fall back to the GeometryDeprecated class? I know the 3ds max exporter plugin generates vertex indices in some cases. Just curious how those existing files will be handled now. Cheers, Farshid On Tue, Jun 4, 2013 at 12:14 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi All, One of the changes I've discussed before, but as yet no made, is to simplify osg::Geometry so that it drops the index arrays that you can currently associated for vertex, normal, colour, texcoord arrays. These index arrays aren't supported by OpenGL, instead have to be emulated by breaking the primitive data up into small chunks and sending the vertex data and primitive data in small batches. This is very inefficient, so what having separate vertex indicies might seem like a good way of reducing vertex data overhead by sharing more it causes a big CPU overhead and results in lower performance. While there are clear warnings in the osg::Geometry header that this feature is deprecated and forces and OpenGL slow path I know it still gets used on occasion - against best practice advice. What I'd like now to do is drop the index arrays from osg::Geometry, and provide a GeometryDeprecated class for the those who need backwards compatibility. Potentially this GeometryDeprecated class could go in the core osg library, but I'm tempted to move it out into one of the optional NodeKits to reduce the size of the core osg library. To be clear OpenGL indexed primitives will still be fully support by osg::Geometry - DrawElement* has always been available and will remain, it's the long been the preferred way to pass your primitive data to OpenGL. Another step in making these changes that I'm considering is moving the normalize parameter from Geometry::ArrayData into osg::Array, with this change ArrayData ceases to have a role and can be removed further simplifying osg::Geometry. Thoughts? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgCompute] Find statistics (min, max, mean, stddev) using NPP or alternative of RTT/FBO
Hi creature, yes, the launch function is exactly where you should call those npp-functions. You get the device pointer by calling myBuffer-map(osgCompute::MAP_DEVICE). If you want to get access to the internal texture memory, call myBuffer-map(osgCompute::MAP_DEVICE_ARRAY) and cast the void* pointer to a cudaArray* pointer. Regards, Jens -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54448#54448 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgCompute] osgCompute restrictions
Hi sajis997, CUDA comes with two programing interfaces: a Driver API and a Runtime API. We currently only support the built in Runtime API with our osgCuda implementation. However it has nothing to do with the display driver or the compute capability. Thus, a gtx 560m and cuda tool-kit 4.2 should work perfectly. Cheers, Jens -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54449#54449 ___ 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 Farshid, On 4 June 2013 18:27, Farshid Lashkari fla...@gmail.com wrote: You mentioned implementing some sort of backwards compatibility for the serialization plugins. Does that mean existing osg files (osg, ive, osgb, etc...) that use indices will automatically fall back to the GeometryDeprecated class? They will either have to create a GeometryDeprecated fill it in and pass it back, or create a GeometryDeprecated fill it in, convert this to the new Geometry and then pass it back. Ideally I'd like GeometryDeprecated placed outwith core osg but this would mean linking plugins with more libraries than what was required before so not ideal. For the time being I think we'll be stuck with GeometryDeprecated are part of the core osg. The automatic detection of indices and falling back to GeometryDeprecated is going to be awkward. Longer term we might be able to automatically map all the old Geometry usage with indices and per primitive bindings directly to the new Geometry and do away with the need to return GeometryDeprecated. The only problem would be if users back the assumption about their availability and rely upon indices or per primitive bindings in the scene graphs they load, perhaps an optional compile would work around this. I know the 3ds max exporter plugin generates vertex indices in some cases. Just curious how those existing files will be handled now. We really want all the plugins we can generating osg::Geometry based scene graphs rather than falling back to GeometryDeprecated. So it would be good to port these old plugins across. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgCompute] Export in osgCuda
Hi sajis997, The export file defines EXPORT/IMPORT macros for all functions in our osgCuda library in case you are using dynamic libraries (i.e. you have set the DYNAMIC_LINKING flag to true in CMake). Nice to hear that you are going to extend osgCompute to OpenCL. I am also in E-Mail contact with someone who currently is implementing an osgOpenCL library. I am not sure if that person is you? But if not than you two should definitely talk. Cheers, Jens -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54450#54450 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgCompute] documentation
Hi sajis997, You are right. osgCuda::Buffer is not documented yet. I am on it! Regards, Jens -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54452#54452 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgCompute] osgTraceDemo
Hi sajis997, You have to install the dynamic libraries first. Otherwise he can't find the libraries. After installing the trace demo should work perfectly. Cheers, Jens -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54453#54453 ___ 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 All, I have now completed the removal of ArrayData container and all slow path support from GeometryNew. The size is now down to less than 2/3rd the size of the original Geometry.cpp. The largest bloat left is with helper functions for verifying and correcting bindings, but I now believe these should be placed into osgUtil as helper functions rather osg::Geometry so I'll likely remove these and the size will go small still. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Edge artifacts with multiple render targets
Hi, I have switched my rendering stuff to deferred rendering, and I noticed some problems around the edges of the hills in the terrain (see attached picture) I write 3 buffers: -color -normal -position (fragment position in world coordinates) I tried finding a problem in the buffers around the edges, but there are none there, they are also aligned with each other. Then I noticed the thing causing the edge problem is the 3d fog. to make the 3d fog I sample multiple times from a 3d texture. The places where I sample from the 3d-texture are only dependent on the camera position (uniform variable) and the fragment positions (from the buffer), so it samples from a line going from camera to fragment positions in a 3d texture. Works really well, and in the non- deferred rendering that i started with I had no edge problems. I inspected the position buffer well, I even exported it to an excel sheet, but there is no edge problem inside that buffer. Also when I replace the 3d fog with linear fog (also based on the exact same camera position and fragment position), there are no problems on the edges anymore. So I can only conclude that when I start sampling from that 3d texture, that somehow influences the final results. It seem that is causes it to do multi-samples on the final quad too, instead of just doing it pixel by pixel. But that is just my idea for now, I'm in no way an expert on the subject. Does anyone understand what is going on, or has ANY tips on how I could try to fix this? I could also post my code on how I create and use the buffers and the 3d fog texture, or the shaders, if that helps. Thanks for any help! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54455#54455 Attachments: http://forum.openscenegraph.org//files/hilledges_982.png ___ 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
robertosfield wrote:
The PreserveDataType and AttribDivisor are entirely
new and are intended to support new extensions being added to the OSG
- but their implementation will have to wait till the GeometryNew
refactor is further down the road.
This is great !
robertosfield wrote:
Alternatively we just drop backwards compatibility and
force uses to set the binding directly on the array.
I prefer this solution, sometimes changes are simply needed.
robertosfield wrote:
The naming of Binding is something I'm note yet sure of, with the
introduction of AttribDivisor the binding becomes a bit less clearly
defined as well. Not sure what to make of this yet...
Maybe a single parameter, something like get/setRate, using an enum :
enum Rate
{
RATE_OFF=0, // Attribute is never emitted =BIND_OFF -
attribDivisor = 0
RATE_SINGLESHOT // Attribute is emitted once =BIND_OVERALL -
attribDivisor = 0
RATE_PRIMITIVE_SET, // Attribute is emitted at each start of a
primitive set = BIND_PRIMITIVE_SET - attribDivisor = 0
RATE_VERTEX , // Attribute is emitted at each vertex =
BIND_VERTEX - attribDivisor = 0
RATE_INSTANCE_0, // Attribute is emitted at each vertex =
BIND_VERTEX - attribDivisor = 0
RATE_INSTANCE_1, // Attribute is emitted at each instance =
BIND_VERTEX - attribDivisor = 1
RATE_INSTANCE_2,// Attribute is emitted at each 2 instances =
BIND_VERTEX - attribDivisor = 2
...
RATE_INSTANCE_9,// Attribute is emitted at each 2 instances =
BIND_VERTEX - attribDivisor = 9
};
Of course, user can do setRate(RATE_INSTANCE_0 + 25) to have attribDivisor = 25
robertosfield wrote:
I have now completed the removal of ArrayData container and all slow
path support from GeometryNew. The size is now down to less than
2/3rd the size of the original Geometry.cpp. The largest bloat left
is with helper functions for verifying and correcting bindings, but I
now believe these should be placed into osgUtil as helper functions
rather osg::Geometry so I'll likely remove these and the size will go
small still.
Great work !
I have a question about immediate mode deprecation : does that mean the array
dispatchers are no more needed ? Do the osg::geometryNew class set
vertex/normal/textcoords... pointers directly on the osg::State ?
And about display list : I understand that it's too early to remove them, in
some situations it's still usefull. But maybe it's time to use it per default ?
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=54456#54456
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Edge artifacts with multiple render targets
Does anyone know: what is the default texture filter mode (for 3d textures) when you do not explicitly set it? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54457#54457 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Edge artifacts with multiple render targets
On 4 June 2013 22:49, Bram Vaessen bram.vaes...@gmail.com wrote: Does anyone know: what is the default texture filter mode (for 3d textures) when you do not explicitly set it? The default filtering for a texture objects is defined in the Texture::Texture() default constructor and is (from OpenSceneGraph/src/osg/Texture.cpp: _min_filter(LINEAR_MIPMAP_LINEAR), // trilinear _mag_filter(LINEAR), I'm afraid when I read your original post I couldn't really work exactly you were doing, and as such didn't have any clues to what might be amiss. Robert. ___ 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 Aurelien,
On 4 June 2013 21:33, Aurelien Albert aurelien.alb...@alyotech.fr wrote:
robertosfield wrote:
The naming of Binding is something I'm note yet sure of, with the
introduction of AttribDivisor the binding becomes a bit less clearly
defined as well. Not sure what to make of this yet...
Maybe a single parameter, something like get/setRate, using an enum :
enum Rate
{
RATE_OFF=0, // Attribute is never emitted =BIND_OFF -
attribDivisor = 0
RATE_SINGLESHOT // Attribute is emitted once =BIND_OVERALL -
attribDivisor = 0
RATE_PRIMITIVE_SET, // Attribute is emitted at each start of a
primitive set = BIND_PRIMITIVE_SET - attribDivisor = 0
RATE_VERTEX , // Attribute is emitted at each vertex =
BIND_VERTEX - attribDivisor = 0
RATE_INSTANCE_0, // Attribute is emitted at each vertex =
BIND_VERTEX - attribDivisor = 0
RATE_INSTANCE_1, // Attribute is emitted at each instance =
BIND_VERTEX - attribDivisor = 1
RATE_INSTANCE_2,// Attribute is emitted at each 2 instances =
BIND_VERTEX - attribDivisor = 2
...
RATE_INSTANCE_9,// Attribute is emitted at each 2 instances =
BIND_VERTEX - attribDivisor = 9
};
Of course, user can do setRate(RATE_INSTANCE_0 + 25) to have attribDivisor =
25
I was wondering about the overlap between AttribDivisor and Binding,
combining the two would avoid issues with users setting
BIND_OVERALL/BIND_PER_PRIMITIVE_SET and AttribDivisor and expecting it
somehow to work.
Right now I feel that sticking with the same naming convention that
users have been used will make for a smoother transition to the new
osg::Geometry. Ideally I want most users just to recompile their code
and not have any problems.. Extending the enum Binding with
BIND_INSTANCE_DIVISOR_0 etc, would be one way, it's a bit cludgy but
would avoid the overlap in functionality issue.
I am busy with other work today so will have to return to this topic tomorrow.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
