Re: [osg-users] shader composition
Hi Nick, On 28 January 2015 at 23:23, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: I read the shader composition code and the used classes - which are really without any documentation :-). Can someone give a fast intro into this, the sample for example? ShaderComposition in the core OSG is still experimental, the osgshadercomposition example is main place to learn about what is supported so far. However, I'm currently working on tackling the problem of shader management from a different direction, if successful it will avoid the need for the previous ShaderoComposition functionality for a range of usage models. I'll discuss this new approach in a separate thread. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShaderComposer and some missing features
Hi Sebastian, I have just re-read this thread and feel the time is right for me to do a review of your changes. Could you provide me with your latest changes? As a general note, the current work I'm doing is focussing on passing #define's into Shaders to toggle on/off features and provide defaults via osg::StateSet::setDefine(..) style API, as well also allow GLSL Shaders themselves to specify what they require via #pragam statements in the GLSL shaders. The new functionality could reduce the need for shader composer. I'm optimistic for many users the approach I'm working on will be simple to use and fit in well with how osg::Program/osg::Shader's have been used in application so far. I will start a new thread today or tomorrow on the topic of my work, but first I need to flesh out a bit more of the design and implementation so I can illustrate what I'm talking about with actual OSG and GLSL code. Cheers, Robert. On 5 February 2014 at 12:01, Sebastian Messerschmidt sebastian.messerschm...@gmx.de wrote: Hi Robert, maybe this one has gone below your radar. Can you please check on it? I've developed this a bit more and found out that I had to provide my own compare function to get rid of the additional program being constructed. If there are no objections from your side I'd like to prepare a submission. cheers Sebastian Hi Robert, I've done my best to follow your instructions. See attached changes vs. trunk. The shadercomposition example still works as expected. Comparing the outputs however, an additional program is build, and I'm quite clueless, if my refactoring is correct (see attached outputs) I'd appreciate some advices here. Hi Sebastian, On 27 November 2013 11:26, Sebastian Messerschmidt sebastian.messerschm...@gmx.de wrote: Okay I can try to refactor it, but I'm not 100% sure if I got you right. Would the caching attribute (last_applied_shadercomponent) still be used then? I'm thinking last_applied_shadercomponent would be redundent and could be removed. Also do you mean by get the last applied StateAttribute's from the AttributeStack to use the last_applied_attribute member? Yes, use last_applied_attribute instead of last_applied_shadercomponent. The code associated with the later could be completely removed from osg::State so would simply it a little. Simplifying code and providing greater extensibility sounds like a good design change to me :-) Robert. ___ osg-users mailing listosg-users@lists.openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing listosg-users@lists.openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [Qt] Create a HUD (by using QGraphicsView / QGraphicsScene )
Hi, I have a look on the osgQtWidgets example but the only HUD create is into the OSG view. I try to found a solution by using Qt Baxos exemple. I can display OSG into QGraphicsScene but I lost all interaction. I found a topic talking about this (I cant post URL yet). Into it, a post talk about osgQtWidgets example but there is no QWidget on a GLWidget exemple. As anyone can help me ? ... Thank you! Cheers, Nicolas -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62514#62514 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FLATTEN_STATIC_TRANSFORMS Not Always Working
Hi all, Den 22.01.2015 14:05, skrev Robert Osfield: There isn't any way for me to know whether you have hit upon a bug or just that the scene graph you are trying to optimize is structured in way that could can eliminate the transforms as I simply don't have a dataset that reproduces it. One of the things that prevent transforms being flattened and then removed is if a subgraph has two parents each with it's own unique transform. I would add that the Optimizer and all it's parts is a sticky plaster fix for bad scene graphs, it tries it's best to fix bad scene graphs but it can't always do everything that could be done. In an ideal world all scene graph would be built optimally in the modelling software and never need this fix up processing. I came across some optimizer issues and try to track down whats going wrong. I have noticed misplaced geometry after loading some of our older FLT databases into latest osgviewer app (using osg trunk). The problem arises when running the optimizer with default optimizations in osgviewer over the loades model. Following default optimizations seem to be in conflict: FLATTEN_STATIC_TRANSFORMS and REMOVE_LOADED_PROXY_NODES The last change on Optimizer.cpp (revision 14388, 29. 07.2014 ) line 1102 has some impact. Without running this change our datebase doesn't get misplaced objects. We try to make a small testdataset to be able to reproduce the issue. Typically these databases was built with multigen, using lots of proxy's , multiple parents, heavy use of LOD's. I try to figure out what is the reason for that we are loosing some transform information, I'm not sure right now. Only thing I can say is that our models worked with the old Optimizer code. Even if our models have a structure that is difficult to optimize , the DEFAULT_OPTIMIZATION settings shouldn't break it. One thing that I also noticed is that converting some of our models takes much more time and RAM than before. I could see that running SHARE_DUPLICATE_STAE and MERGE_GEOMETRY is taking much time / RAM. Having a small testmodel is probably the best way to solve this, we are trying to make one that is simple, but using the same structure as used in our databases. regards, Markus ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FLATTEN_STATIC_TRANSFORMS Not Always Working
Hi Markus, Absolutely the Optimizer shouldn't break scene graphs, it should only replace with scene graph elements that reproduce the same result, if it doesn't then there is a bug in either the transformations or applying modifications where none should be. W.r.t. model size growing after, typically it goes down, including when optimizing OpenFlight databases. If it's taking more memory it could be a bug, or inappropriate operations being applied. I can't say anything specific though, as I don't have the data, I simply don't know what might be amiss. Robert. On 29 January 2015 at 10:05, Markus Hein mah...@frisurf.no wrote: Hi all, Den 22.01.2015 14:05, skrev Robert Osfield: There isn't any way for me to know whether you have hit upon a bug or just that the scene graph you are trying to optimize is structured in way that could can eliminate the transforms as I simply don't have a dataset that reproduces it. One of the things that prevent transforms being flattened and then removed is if a subgraph has two parents each with it's own unique transform. I would add that the Optimizer and all it's parts is a sticky plaster fix for bad scene graphs, it tries it's best to fix bad scene graphs but it can't always do everything that could be done. In an ideal world all scene graph would be built optimally in the modelling software and never need this fix up processing. I came across some optimizer issues and try to track down whats going wrong. I have noticed misplaced geometry after loading some of our older FLT databases into latest osgviewer app (using osg trunk). The problem arises when running the optimizer with default optimizations in osgviewer over the loades model. Following default optimizations seem to be in conflict: FLATTEN_STATIC_TRANSFORMS and REMOVE_LOADED_PROXY_NODES The last change on Optimizer.cpp (revision 14388, 29. 07.2014 ) line 1102 has some impact. Without running this change our datebase doesn't get misplaced objects. We try to make a small testdataset to be able to reproduce the issue. Typically these databases was built with multigen, using lots of proxy's , multiple parents, heavy use of LOD's. I try to figure out what is the reason for that we are loosing some transform information, I'm not sure right now. Only thing I can say is that our models worked with the old Optimizer code. Even if our models have a structure that is difficult to optimize , the DEFAULT_OPTIMIZATION settings shouldn't break it. One thing that I also noticed is that converting some of our models takes much more time and RAM than before. I could see that running SHARE_DUPLICATE_STAE and MERGE_GEOMETRY is taking much time / RAM. Having a small testmodel is probably the best way to solve this, we are trying to make one that is simple, but using the same structure as used in our databases. regards, Markus ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ClipTexture and OpenSceneGraph
Hi, We are about to port an application from Performer that makes use of ClipTextures. What is the equivalent in OpenSceneGraph or is there an alternative way to get the same feature. For a definition of a ClipTexture see http://techpubs.sgi.com/library/dynaweb_docs/0620/SGI_Developer/books/Perf_PG/sgi_html/ch12.html Thank you! Cheers, Tony -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62518#62518 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShaderComposer and some missing features
Am 29.01.2015 um 11:17 schrieb Robert Osfield: Hi Sebastian, I have just re-read this thread and feel the time is right for me to do a review of your changes. Could you provide me with your latest changes? See attached files. It more or less allows to create an own StateAttribute which in my case holds the defines etc. As for the framework I built around this to add includes etc. : It relies on boost/string etc. so it won't be of direct use. As a general note, the current work I'm doing is focussing on passing #define's into Shaders to toggle on/off features and provide defaults via osg::StateSet::setDefine(..) style API, as well also allow GLSL Shaders themselves to specify what they require via #pragam statements in the GLSL shaders. The new functionality could reduce the need for shader composer. I'm optimistic for many users the approach I'm working on will be simple to use and fit in well with how osg::Program/osg::Shader's have been used in application so far. Now that would be great! Indeed this is what I tried to emulate with the ShaderComposition. The changes that I did, where required to do things like adding glBindFragment at the states. I deferred setting up state like this by reimplementing the getOrCreateProgram virtual function of the ShaderComposer. But this would be totally obsolete then. Maybe it can totally replace my approach and provide some test-bed for the new approach. Will there be some mechanism creating a new program object when add a define somewhere below an existing program, like the shader composition did? Also i'd like to undefine on the way/ remove a define/ clear the define-set somewhere in the hierarchy, will this be covered by ON/OFF, OVERRIDE/PROTECTED mechanism of the state-attribute? For example: Group (with osg::Program X in stateset) || | stateset A with define dA -program with code of X and defines dA || | ... | stateset B with define dB - program with code of X and defines dA dB | stateset C with define dC - program with code of X and define C Cheers Sebastian I will start a new thread today or tomorrow on the topic of my work, but first I need to flesh out a bit more of the design and implementation so I can illustrate what I'm talking about with actual OSG and GLSL code. Cheers, Robert. On 5 February 2014 at 12:01, Sebastian Messerschmidt sebastian.messerschm...@gmx.de mailto:sebastian.messerschm...@gmx.de wrote: Hi Robert, maybe this one has gone below your radar. Can you please check on it? I've developed this a bit more and found out that I had to provide my own compare function to get rid of the additional program being constructed. If there are no objections from your side I'd like to prepare a submission. cheers Sebastian Hi Robert, I've done my best to follow your instructions. See attached changes vs. trunk. The shadercomposition example still works as expected. Comparing the outputs however, an additional program is build, and I'm quite clueless, if my refactoring is correct (see attached outputs) I'd appreciate some advices here. Hi Sebastian, On 27 November 2013 11:26, Sebastian Messerschmidt sebastian.messerschm...@gmx.de mailto:sebastian.messerschm...@gmx.de wrote: Okay I can try to refactor it, but I'm not 100% sure if I got you right. Would the caching attribute (last_applied_shadercomponent) still be used then? I'm thinking last_applied_shadercomponent would be redundent and could be removed. Also do you mean by get the last applied StateAttribute's from the AttributeStack to use the last_applied_attribute member? Yes, use last_applied_attribute instead of last_applied_shadercomponent. The code associated with the later could be completely removed from osg::State so would simply it a little. Simplifying code and providing greater extensibility sounds like a good design change to me :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto: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] shader composition
On 29.1.2015 0:23, Trajce Nikolov NICK wrote: I read the shader composition code and the used classes - which are really without any documentation:-). Can someone give a fast intro into this, the sample for example? Thanks a bunch as always Hi Nick, I once did some experimental coding on shader composition. The idea was to emulte all the FFP attributes with shaders and possibly extend the composition with custom shaders. Although the code is working and it produces optimal shaders with zero branching or defines, I have never had time to polish it up and send it for a review. I could post the sample I used for testing, if you are interested. The bad news is that it requires some osg core modifications to work properly. I can send those, too. Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShaderComposer and some missing features
Hi Sebastien, Thanks for the modified files. Will be reviewing them this afternoon. Will there be some mechanism creating a new program object when add a define somewhere below an existing program, like the shader composition did? That's my intention. The per context program object will contain a list of GL program object id's, one for each configuration of defines so far applied. As new combinations are introduced a new problem is compiled/linked, but if one has already been created for that combination then it's reused. Also i'd like to undefine on the way/ remove a define/ clear the define-set somewhere in the hierarchy, will this be covered by ON/OFF, OVERRIDE/PROTECTED mechanism of the state-attribute? Yes, this will be possible via: stateset-add/setDefine(MY_DEFINE, osg::StateAttribute::OFF); Or at least that's my thought. Effectively the Define will behave a bit like StateSet::setMode(...). You'll also be able to associated values with a define too i,e. stateset-addDefine(BASE_COLOR,vec4(1.0,0.0,0.0,1.0)); Which be automatically included in GLSL shader, that have a #pragma import_define(BASE_COLOR) to give you: #define BASE_COLOR vec4(1.0,0.0,0.0,1.0) And used there after in the GLSL: #ifdef BASE_COLOR vec4 mycolor = BASE_COLOR; #else vec4 mycolor = vec4(1.0,1.0,1.0,1.0); // optional fallback #endif Whole shaders can be optionally included in the Program as well, via the #pragma requires(MY_DEFINE), so if no MY_DEFINE is provided in the osg::StateSet hierarchy in the scene graph then it won't link that shader. This is useful if you have a osg::Program that contains a geometry shader that you want to toggle on/off when it's needed or not. For example: Group (with osg::Program X in stateset) || | stateset A with define dA -program with code of X and defines dA || | ... | stateset B with define dB - program with code of X and defines dA dB | stateset C with define dC - program with code of X and define C Yep, that's the idea at least. Have to implement it now :-) What this approach should assist is provided uber osg::Program at the top of subgraph that can lots of different options just like the fixed function pipeline currently does. To tie the approach into the old fixed function pipeline approach I'm also thinking about define name to GL enum value mapping, so for instance doing a stateset-setMode(GL_LIGHTING, osg::StateAttribute::ON) would be mapped to a GL_LIGHTING define. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShaderComposer and some missing features
Hi Robert, Hi Sebastien, (SebastiAn ;-) That's really great news and I cannot wait to replace my messy code with such core feature :-) If you need help testing/use cases, feel free to contact me. Cheers Sebastian Thanks for the modified files. Will be reviewing them this afternoon. Will there be some mechanism creating a new program object when add a define somewhere below an existing program, like the shader composition did? That's my intention. The per context program object will contain a list of GL program object id's, one for each configuration of defines so far applied. As new combinations are introduced a new problem is compiled/linked, but if one has already been created for that combination then it's reused. Also i'd like to undefine on the way/ remove a define/ clear the define-set somewhere in the hierarchy, will this be covered by ON/OFF, OVERRIDE/PROTECTED mechanism of the state-attribute? Yes, this will be possible via: stateset-add/setDefine(MY_DEFINE, osg::StateAttribute::OFF); Or at least that's my thought. Effectively the Define will behave a bit like StateSet::setMode(...). You'll also be able to associated values with a define too i,e. stateset-addDefine(BASE_COLOR,vec4(1.0,0.0,0.0,1.0)); Which be automatically included in GLSL shader, that have a #pragma import_define(BASE_COLOR) to give you: #define BASE_COLOR vec4(1.0,0.0,0.0,1.0) And used there after in the GLSL: #ifdef BASE_COLOR vec4 mycolor = BASE_COLOR; #else vec4 mycolor = vec4(1.0,1.0,1.0,1.0); // optional fallback #endif Whole shaders can be optionally included in the Program as well, via the #pragma requires(MY_DEFINE), so if no MY_DEFINE is provided in the osg::StateSet hierarchy in the scene graph then it won't link that shader. This is useful if you have a osg::Program that contains a geometry shader that you want to toggle on/off when it's needed or not. For example: Group (with osg::Program X in stateset) || | stateset A with define dA -program with code of X and defines dA || | ... | stateset B with define dB - program with code of X and defines dA dB | stateset C with define dC - program with code of X and define C Yep, that's the idea at least. Have to implement it now :-) What this approach should assist is provided uber osg::Program at the top of subgraph that can lots of different options just like the fixed function pipeline currently does. To tie the approach into the old fixed function pipeline approach I'm also thinking about define name to GL enum value mapping, so for instance doing a stateset-setMode(GL_LIGHTING, osg::StateAttribute::ON) would be mapped to a GL_LIGHTING define. 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] SmoothingVisitor normals doesn't seem right
Hi AP, two ideas: Play with sv-setCreaseAngle(something else than default PI) or yourNode-getOrCreateStateSet()-setAttributeAndModes(new osg::FrontFace(osg::FrontFace::COUNTER_CLOCKWISE), osg::StateAttribute::ON); (CLOCKWISE or COUNTER_CLOCKWISE that is) Hope this helps, /Per On 27 January 2015 at 11:54, Ash Pat ash_zz...@yahoo.com wrote: Hi, I am trying to use the SmoothingVisitor to generate the normals. I am not explicitly setting the normals array. However, when rendered it appears as though the normals generated are flipped. The geometry consists of triangle and quad primitives. I tried it in two ways. Code: osgUtil::SmoothingVisitor::smooth(*pGeometry); Code: osgUtil::SmoothingVisitor sv; pGeode-accept(sv); Any suggestions? Is there something more to be done? Thank you! Cheers, AP -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62491#62491 ___ 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] shader composition
Thanks Robert, Robert, I will wait for the new code then. Nick On Thu, Jan 29, 2015 at 11:54 AM, Robert Milharcic robert.milhar...@ib-caddy.si wrote: On 29.1.2015 0:23, Trajce Nikolov NICK wrote: I read the shader composition code and the used classes - which are really without any documentation:-). Can someone give a fast intro into this, the sample for example? Thanks a bunch as always Hi Nick, I once did some experimental coding on shader composition. The idea was to emulte all the FFP attributes with shaders and possibly extend the composition with custom shaders. Although the code is working and it produces optimal shaders with zero branching or defines, I have never had time to polish it up and send it for a review. I could post the sample I used for testing, if you are interested. The bad news is that it requires some osg core modifications to work properly. I can send those, too. Robert Milharcic ___ 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] [build] Building OSG libraries for Android example
So, I have tried the Cygwin 'MAKE' route today and as I expected, got stuck :-( If the following is useful to help stimulate some feedback, please feel free. To me it looks like something is trying to define a variable twice, but from the same .mk file???. $ make [100%] Generating Android-OpenSceneGraph HOST_OS=cygwin HOST_ARCH=x86_64 HOST_TAG=cygwin-x86 (no 64-bit prebuilt binaries detected) GNUMAKE=/usr/bin/make (system path) Cygwin-compatible GNU make detected Android NDK: NDK installation path auto-detected: '/cygdrive/c/android/ndk' Android NDK: GNU Make version 4.0 detected Android NDK: Host OS was auto-detected: windows Android NDK: Found /bin/uname.exe on Windows host Android NDK: uname -s returned: CYGWIN_NT-6.1 Android NDK: Cygwin detected: CYGWIN_NT-6.1 398L3X1 1.7.33-2(0.280/5/3) 2014-11-13 15:47 x86_64 Cygwin Android NDK: Host operating system detected: cygwin Android NDK: Host CPU was auto-detected: x86 Android NDK: HOST_TAG set to windows Android NDK: Host tools prebuilt directory: /cygdrive/c/android/ndk/prebuilt/windows-x86_64/bin Android NDK: Host 'echo' tool: echo Android NDK: Host 'echo -n' tool: printf %s Android NDK: Host 'cmp' tool: /cygdrive/c/android/ndk/prebuilt/windows-x86_64/bin/cmp Android NDK: Host 'awk' tool: awk Android NDK: Host 'awk' test returned: Pass Android NDK: Probing for 'cygpath' program Android NDK: 'cygpath' found as: /usr/bin/cygpath Using cygwin substitution rules: /cygdrive/z = Z: /cygdrive/x = X: /cygdrive/s = S: /cygdrive/q = Q: /cygdrive/o = O: /cygdrive/n = N: /cygdrive/m = M: /cygdrive/l = L: /cygdrive/k = K: /cygdrive/j = J: /cygdrive/g = G: /cygdrive/c = C: /cygdrive/Z = Z: /cygdrive/X = X: /cygdrive/S = S: /cygdrive/Q = Q: /cygdrive/O = O: /cygdrive/N = N: /cygdrive/M = M: /cygdrive/L = L: /cygdrive/K = K: /cygdrive/J = J: /cygdrive/G = G: /cygdrive/C = C: /usr/lib = C:/cygwin64/lib /usr/bin = C:/cygwin64/bin / = C:/cygwin64 Android NDK: Found platform root directory: /cygdrive/c/android/ndk/platforms Android NDK: Found supported platforms: android-4 android-17 android-18 android-19 android-13 android-3 android-14 android-15 android-8 android-9 android-16 android-21 android-12 android-5 Android NDK: PLATFORM android-4 supports: arm Android NDK: ABI arm sysroot is: /cygdrive/c/android/ndk/platforms/android-4/arch-arm Android NDK: PLATFORM android-17 supports: x86 arm mips Android NDK: ABI x86 sysroot is: /cygdrive/c/android/ndk/platforms/android-17/arch-x86 Android NDK: ABI arm sysroot is: /cygdrive/c/android/ndk/platforms/android-17/arch-arm Android NDK: ABI mips sysroot is: /cygdrive/c/android/ndk/platforms/android-17/arch-mips Android NDK: PLATFORM android-18 supports: x86 arm mips Android NDK: ABI x86 sysroot is: /cygdrive/c/android/ndk/platforms/android-18/arch-x86 Android NDK: ABI arm sysroot is: /cygdrive/c/android/ndk/platforms/android-18/arch-arm Android NDK: ABI mips sysroot is: /cygdrive/c/android/ndk/platforms/android-18/arch-mips Android NDK: PLATFORM android-19 supports: x86 arm mips Android NDK: ABI x86 sysroot is: /cygdrive/c/android/ndk/platforms/android-19/arch-x86 Android NDK: ABI arm sysroot is: /cygdrive/c/android/ndk/platforms/android-19/arch-arm Android NDK: ABI mips sysroot is: /cygdrive/c/android/ndk/platforms/android-19/arch-mips Android NDK: PLATFORM android-13 supports: x86 arm mips Android NDK: ABI x86 sysroot is: /cygdrive/c/android/ndk/platforms/android-13/arch-x86 Android NDK: ABI arm sysroot is: /cygdrive/c/android/ndk/platforms/android-13/arch-arm Android NDK: ABI mips sysroot is: /cygdrive/c/android/ndk/platforms/android-13/arch-mips Android NDK: PLATFORM android-3 supports: arm Android NDK: ABI arm sysroot is: /cygdrive/c/android/ndk/platforms/android-3/arch-arm Android NDK: PLATFORM android-14 supports: x86 arm mips Android NDK: ABI x86 sysroot is: /cygdrive/c/android/ndk/platforms/android-14/arch-x86 Android NDK: ABI arm sysroot is: /cygdrive/c/android/ndk/platforms/android-14/arch-arm Android NDK: ABI mips sysroot is: /cygdrive/c/android/ndk/platforms/android-14/arch-mips Android NDK: PLATFORM android-15 supports: x86 arm mips Android NDK: ABI x86 sysroot is: /cygdrive/c/android/ndk/platforms/android-15/arch-x86 Android NDK: ABI arm sysroot is: /cygdrive/c/android/ndk/platforms/android-15/arch-arm Android NDK: ABI mips sysroot is: /cygdrive/c/android/ndk/platforms/android-15/arch-mips Android NDK: PLATFORM android-8 supports: arm Android NDK: ABI arm sysroot is: /cygdrive/c/android/ndk/platforms/android-8/arch-arm Android NDK: PLATFORM android-9 supports: x86 arm mips Android NDK: ABI x86 sysroot is: /cygdrive/c/android/ndk/platforms/android-9/arch-x86 Android NDK: ABI arm sysroot is: /cygdrive/c/android/ndk/platforms/android-9/arch-arm Android NDK: ABI mips sysroot is: /cygdrive/c/android/ndk/platforms/android-9/arch-mips Android NDK: PLATFORM android-16 supports: x86 arm mips Android NDK: ABI x86 sysroot is:
Re: [osg-users] ClipTexture and OpenSceneGraph
Hi Tony, I'm not aware of this functionality in stock osg, so looks like you should search for virtual texture of sparse texture OpenGL extension or similar terms ( MegaTexture etc ) on the net. few links with code examples you might find useful http://sourceforge.net/projects/libvt/ it is claimed to work with OpenSceneGraph https://github.com/g-truc/ogl-samples has sparse texture example, see also http://www.tinysg.de/techGuides/tg4_prt.html https://bitbucket.org/hybird/moquette/src/3cf8f3ba2fcb9df70798c0cc66468e5a109fcd42?at=default - is a virtual texture plugin for Ogre Regards Sergey On Thu, Jan 29, 2015 at 3:05 PM, Tony Vasile ming...@gmail.com wrote: Hi, We are about to port an application from Performer that makes use of ClipTextures. What is the equivalent in OpenSceneGraph or is there an alternative way to get the same feature. For a definition of a ClipTexture see http://techpubs.sgi.com/library/dynaweb_docs/0620/SGI_Developer/books/Perf_PG/sgi_html/ch12.html Thank you! Cheers, Tony -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62518#62518 ___ 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
