Re: [osg-users] Setting the transform matrices
Thanks for the informative reply, much appreciated. robertosfield wrote: > I have run with the various command 1-8 options and get different behaviour > but looking at the code I really don't know what is expected. The black cow > is likely occurring because no shader is being provided that handles texgen > that the cow.osg uses from the fixed function pipeline. Based on your earlier response here .. robertosfield wrote: > you don't need to add ANY more complexity than just replacing gl_ModelView* > with osg_ModelView*, the OSG will even automatically remap for you. > > > The OSG automatically accumulates all view and projection matrices for you, > sets the when required, it does a shed load of work for you to make you life > easy. All the osg::Camera and osg::Transform subclasses all work in coherent > and robust fashion, whether you are using fixed function pipeline of shaders > and they function in the same way in both. .. I would have thought the expected behavior is that using vertex attrib aliasing and use model/view/projection uniforms would work because osg remaps etc and replaces fixed transforms and deprecated gl_ uniforms with osg_ uniforms. I realize the difficulty / impossibility of automatically taking people from fixed function / legacy shaders to modern GL. But that's what prompted this thread; that it seems difficult to hook into the power of OSG in a modern GL context. robertosfield wrote: > In OSG-3.4.x there isn't good automatic way to mix and match fixed function > and shader, the use of the vertex aliasing etc. also doesn't help matters. > It's an area where OpenGL drops us in it, it's either shaders or fixed > function, OpenGL provides no mapping for us to leverage, particularly when > building GL3/core profile or GLES2 where built ins't like glLight etc. have > no gl_Light uniforms associated with them like there is in GL2. > > > The OSG tries to walk between there two worlds - fixed function and shader > based, you can mix and match a bit but it's not seamless, and once you start > talking about GL3/core profule and GLES2 there's a whole heap more things to > deal with and you essentially have to build everything with your own shaders. Agreed 100%; my problem is that building your own shaders within OSG currently has a couple of seemingly minor, but quite frustrating, stumbling blocks. For me the main one is that if you're using your own shaders you need to be able to access the model/view/projection matrices and set them within your own shaders. Right now I need to write my shader with osg_ModelView* as a uniform, which means you need to set setUseModelViewAndProjectionUniforms. This then breaks other legacy shaders since it's a global flag for the state. It seems like if there was a way to set the matrices as uniforms like any other, by giving a hook so that you can define your own behavior when OSG wants to change the matrices during drawing, then I could selectively choose where and when to use fixed and modern. The value of OSG for us is in scene organization, memory management, wrapping around C-oriented OpenGL calls, multiple data format handling, culling, all the libraries built around it, sensible and flexible design, etc. The value of modern shader pipelines is being able to take a set of input uniforms, vertex attributes and texture maps, and have lots of rendering flexibility from that. i.e. I don't need OSG to be able to take a legacy / modern project mixed up and be able to sort it all out. osg::Fog and Light and Particles and Shadows I am happy to leave to legacy because in a modern pipeline world you want to do that yourself. I would like OSG to offer something where it says: "I have figured out the render order, transformation matrices, loaded up the textures, set the vertex attribs, applied your shader programs and applied the global uniforms, done all that magic: Now for this sub-tree as requested you can set the bindings, and I won't try and look inside your shader program and modify it." robertosfield wrote: > So for your example, well you've written an test case that tries to walk the > line between fixed function and shader worlds and area that doesn't isn't > properly supported by OSG-3.4. > > > In the shader_pipeline branch of the OSG master there is some work that > attempts to bridge the gap between fixed function and shaders by providing a > solution for mapping fixed function state attributes to uniforms and > providing shader composition but it's a bleeding edge work in progress. > Getting a seamless mashup isn't a really tough nut to crack, but > shader_pipeline is our current best attempt at this. > > > For your own application you'll need to decide what your goals and > constraints are - if you have to support GL3/core profile and/or GLES2+ then > you'll need to think about how you provide your own shaders and how you remap > fixed function models into your shader
Re: [osg-users] Setting the transform matrices
No worries, thanks anyway http://www.hrwallingford.com/facilities/ship-simulation-centre (http://www.hrwallingford.com/facilities/ship-simulation-centre) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72084#72084 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting the transform matrices
I would be interested and grateful to know what you think of the (apparent) bug I posted Robert, if you get a chance! The code I posted should compile, and you just need to feed in different numbers to the first command line arg to see the effects of changing the vertex attrib and matrix uniform settings. http://www.hrwallingford.com/facilities/ship-simulation-centre (http://www.hrwallingford.com/facilities/ship-simulation-centre) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72079#72079 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CullVisitor::apply(Geode&) detected NaN,
I would run your app in debug mode, break in CullVisitor::apply(osg::Geode), then take a look at the matrix stacks and see where the nans are coming from http://www.hrwallingford.com/facilities/ship-simulation-centre (http://www.hrwallingford.com/facilities/ship-simulation-centre) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=71600#71600 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting the transform matrices
Oops, forgot that most readers are on the mailing list. Here is the code which
breaks with vertex attrib aliasing:
Code:
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2010 Robert Osfield
*
* This application is open source and may be redistributed and/or modified
* freely and without restriction, both in commercial and non commercial
applications,
* as long as this copyright notice is maintained.
*
* This application is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
void createFountainEffect(osgParticle::ModularEmitter* emitter,
osgParticle::ModularProgram* program)
{
// Emit specific number of particles every frame
osg::ref_ptr rrc = new
osgParticle::RandomRateCounter;
rrc->setRateRange(500, 2000);
// Accelerate particles in the given gravity direction.
osg::ref_ptr accel = new
osgParticle::AccelOperator;
accel->setToGravity();
// Multiply each particle's velocity by a damping constant.
osg::ref_ptr damping = new
osgParticle::DampingOperator;
damping->setDamping(0.9f);
// Bounce particles off objects defined by one or more domains.
// Supported domains include triangle, rectangle, plane, disk and
sphere.
// Since a bounce always happens instantaneously, it will not work
correctly with unstable delta-time.
// At present, even the floating error of dt (which are applied to
ParticleSystem and Operator separately)
// causes wrong bounce results. Some one else may have better solutions
for this.
osg::ref_ptr bounce = new
osgParticle::BounceOperator;
bounce->setFriction(-0.05);
bounce->setResilience(0.35);
bounce->addDiskDomain(osg::Vec3(0.0f, 0.0f, -2.0f), osg::Z_AXIS, 8.0f);
bounce->addPlaneDomain(osg::Plane(osg::Z_AXIS, 5.0f));
// Kill particles going inside/outside of specified domains.
osg::ref_ptr sink = new
osgParticle::SinkOperator;
sink->setSinkStrategy(osgParticle::SinkOperator::SINK_OUTSIDE);
sink->addSphereDomain(osg::Vec3(), 20.0f);
emitter->setCounter(rrc.get());
program->addOperator(accel.get());
program->addOperator(damping.get());
program->addOperator(bounce.get());
program->addOperator(sink.get());
}
const std::string
OSG_DATA_FOLDER("C:/Users/User/Desktop/OpenSceneGraph/OpenSceneGraph-Data/");
int main(int argc, char** argv)
{
auto useVertexAttributeAliasing = false;
auto useModelViewAndProjectionUniforms = true;
bool useShaders = false;
if (argc > 1) {
auto caseNo = atoi(argv[1]);
// 8 pemutations of 3 options, 0-7
// Case 4 : Black cow
// Case 5 : Black cow, purple particle smoke
// Case 6 : Black cow
useVertexAttributeAliasing = (0x4 & caseNo)!=0;
useModelViewAndProjectionUniforms = (0x2 & caseNo) != 0;
useShaders = (0x1 & caseNo) != 0;
}
// use an ArgumentParser object to manage the program arguments.
osg::ArgumentParser arguments(, argv);
osgViewer::Viewer viewer(arguments);
std::string textureFile(OSG_DATA_FOLDER + "Images/smoke.rgb");
while (arguments.read("--texture", textureFile)) {}
float pointSize = 20.0f;
while (arguments.read("--point", pointSize)) {}
double visibilityDistance = -1.0f;
while (arguments.read("--visibility", visibilityDistance)) {}
bool customShape = false;
while (arguments.read("--enable-custom")) { customShape = true; }
unsigned int helpType = 0;
if ((helpType = arguments.readHelpType()))
{
arguments.getApplicationUsage()->write(std::cout, helpType);
return 1;
}
// report any errors if they have occurred when parsing the program
arguments.
if (arguments.errors())
{
arguments.writeErrorMessages(std::cout);
return 1;
}
// set up the camera manipulators.
{
osg::ref_ptr
keyswitchManipulator = new osgGA::KeySwitchMatrixManipulator;
keyswitchManipulator->addMatrixManipulator('1', "Trackball",
new osgGA::TrackballManipulator());
keyswitchManipulator->addMatrixManipulator('2', "Flight", new
osgGA::FlightManipulator());
keyswitchManipulator->addMatrixManipulator('3', "Drive", new
osgGA::DriveManipulator());
Re: [osg-users] using modern shaders with osg - setting vertex attribute layout
I'm also transitioning a legacy GL OSG project with a mix of custom shaders to modern GL bit by bit. And I've also had lots of trouble and headache with the built-in modern GL vertex attrib aliasing setting. It seems crazy that the official advice is to write shaders and use OSG just like legacy GL, and OSG will then change your shader code and reinterpret deprecated calls to make it work via "modern" GL: Obviously in years to come when GL newcomers want to use OSG the official line can't be "learn how GL was 20 years ago, write your OSG code like that, and the system will make it work". So I'm afraid this isn't as simple as it could be, but of course it's still easier than converting raw GL calls.. Here is my only advice since I'm not yet finished myself: My recommendation is just leave that attrib aliasing setting alone; you can use modern GL anyway. Just make sure that you use the setVertexAttribute() calls instead of setTextureCoords() / setNormals() / etc, and use the same attrib location numbering convention as OSG (I believe NVidia's drivers enforce those conventions, so you can get the vertex positions at loc=0). Then you'll want to get a copy of the ShaderGen class so you can customize because you'll likely want to modify it yourself. You can use this code to hook into osgDB::readNode()'s behavior to setup your shaders/attribs/etc the way you want. You then need to set useModelViewUniforms, which seems to be less harmful than useVertexAttribAliasing and will make sure osg_ModelViewMatrix is set. Interested to compare notes on how you go anyway http://www.hrwallingford.com/facilities/ship-simulation-centre (http://www.hrwallingford.com/facilities/ship-simulation-centre) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=71598#71598 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting the transform matrices
Fair enough.. I do understand the frustration of supporting unfamiliar devs in
an FOSS project.
I already understand and agree with your post, but I think you took me wrong
I'm not making a big deal out of anything and value OSG highly.
Based on your post I'll move on to something more concrete: Attached is a
example OSG program in OSG 3.4.1 demonstrating vertex attribute aliasing
causing issues.
There are 8 option permutations to try viewing cow.osg and a osgParticle system
with vertex attribute aliasing, uniforms, and shader based particles either on
or off. A number provided as a command line arg decides the case.
The results are:
Code:
// 8 pemutations of 3 options, 0-7
// Case 4 : Black cow (vertex attrib aliasing)
// Case 5 : Black cow, purple particle smoke (vertex attrib
aliasing, shaders)
// Case 6 : Black cow (vertex attrib aliasing,
modelviewandprojectionuniforms)
// Other cases: Shiny cow, white particles
And I can't seem to turn it on only for the required programs and off otherwise.
Since I can't use legacy gl_* uniforms/attribs in modern shaders you need OSG
to set them or to set them yourself. And if you can't enable vertex attrib
aliasing or modelviewandprojectionuniforms because they break other things as
above you can end up trying unusual things and causing grief on the support
mailing list.
http://www.hrwallingford.com/facilities/ship-simulation-centre
(http://www.hrwallingford.com/facilities/ship-simulation-centre)
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=71568#71568
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2010 Robert Osfield
*
* This application is open source and may be redistributed and/or modified
* freely and without restriction, both in commercial and non commercial
applications,
* as long as this copyright notice is maintained.
*
* This application is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
void createFountainEffect(osgParticle::ModularEmitter* emitter,
osgParticle::ModularProgram* program)
{
// Emit specific number of particles every frame
osg::ref_ptr rrc = new
osgParticle::RandomRateCounter;
rrc->setRateRange(500, 2000);
// Accelerate particles in the given gravity direction.
osg::ref_ptr accel = new
osgParticle::AccelOperator;
accel->setToGravity();
// Multiply each particle's velocity by a damping constant.
osg::ref_ptr damping = new
osgParticle::DampingOperator;
damping->setDamping(0.9f);
// Bounce particles off objects defined by one or more domains.
// Supported domains include triangle, rectangle, plane, disk and
sphere.
// Since a bounce always happens instantaneously, it will not work
correctly with unstable delta-time.
// At present, even the floating error of dt (which are applied to
ParticleSystem and Operator separately)
// causes wrong bounce results. Some one else may have better solutions
for this.
osg::ref_ptr bounce = new
osgParticle::BounceOperator;
bounce->setFriction(-0.05);
bounce->setResilience(0.35);
bounce->addDiskDomain(osg::Vec3(0.0f, 0.0f, -2.0f), osg::Z_AXIS, 8.0f);
bounce->addPlaneDomain(osg::Plane(osg::Z_AXIS, 5.0f));
// Kill particles going inside/outside of specified domains.
osg::ref_ptr sink = new
osgParticle::SinkOperator;
sink->setSinkStrategy(osgParticle::SinkOperator::SINK_OUTSIDE);
sink->addSphereDomain(osg::Vec3(), 20.0f);
emitter->setCounter(rrc.get());
program->addOperator(accel.get());
program->addOperator(damping.get());
program->addOperator(bounce.get());
program->addOperator(sink.get());
}
const std::string
OSG_DATA_FOLDER("C:/Users/User/Desktop/OpenSceneGraph/OpenSceneGraph-Data/");
int main(int argc, char** argv)
{
auto useVertexAttributeAliasing = false;
auto useModelViewAndProjectionUniforms = true;
bool useShaders = false;
if (argc > 1) {
auto caseNo = atoi(argv[1]);
// 8 pemutations of 3 options, 0-7
// Case 4 : Black cow
// Case 5 : Black cow, purple particle smoke
// Case 6 : Black cow
useVertexAttributeAliasing = (0x4 & caseNo)!=0;
useModelViewAndProjectionUniforms = (0x2 & caseNo) != 0;
Re: [osg-users] Setting the transform matrices
Hi Robert, For now it'd be too time consuming to isolate a test case. Supporting modern OpenGL does seem like it would be more natural if you had some way of hooking into the setting of the model matrix and vertex attributes so that you could assign / name / alter them yourself. Cheers, Chris http://www.hrwallingford.com/facilities/ship-simulation-centre (http://www.hrwallingford.com/facilities/ship-simulation-centre) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=71557#71557 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting the transform matrices
The problem is whenever I try to use gc->getState()->setUseModelViewAndProjectionUniforms(true); gc->getState()->setUseVertexAttributeAliasing(true); it always seems to screw up something, like the precipitation or particle effects. I figure if there is a way I can set the projection matrices etc to new variables, instead of overwriting existing gl_whatever variables in shaders, then I can supply my shaders with the data they need without affecting anything else. http://www.hrwallingford.com/facilities/ship-simulation-centre (http://www.hrwallingford.com/facilities/ship-simulation-centre) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=71396#71396 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Setting the transform matrices
Hi, What is the proper way to set the view/projection matrix to a uniform yourself? I've found that trying to deal with the osg_ built-in uniforms which do all sorts of renaming etc is unreliable and would like to be able to just set everything myself manually. At the moment I'm setting the view / projection matrix uniforms within the camera's initialdrawcallback, but I'm not sure if this is the right way to do it that will ensure the uniform value will only be used within that camera and not within other cameras (since it needs to work across multiple screens and render stages). Is there some code within OSG that ensures that a uniform assigned to a camera will only apply to the graphics context for the thread that set it? Thank you! Cheers, Chris http://www.hrwallingford.com/facilities/ship-simulation-centre (http://www.hrwallingford.com/facilities/ship-simulation-centre) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=71391#71391 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setUseVertexAttributeAliasing and frame buffer objects not working together
Wow, can't believe my luck at stumbling into the solution for this so quickly..
Code:
osgViewer::Viewer::Windows windows;
viewer.getWindows(windows);
for(osgViewer::Viewer::Windows::iterator itr = windows.begin();
itr != windows.end();
++itr)
{
osg::State *s=(*itr)->getState();
s->resetVertexAttributeAlias(false, 8); // <-- This line
s->setUseModelViewAndProjectionUniforms(true);
s->setUseVertexAttributeAliasing(true);
}
Here is a before / after: http://imgur.com/a/aWoKB
It looks like if you use vertex attribute aliasing it compacts the uniform
slots by default, which screws up all fixed transform stuff (which I guess
expects them to be in their usual spots).
s->resetVertexAttributeAlias(false, 8); prevents it from compacting the uniform
slots, and it all works.
http://www.hrwallingford.com/facilities/ship-simulation-centre
(http://www.hrwallingford.com/facilities/ship-simulation-centre)
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=66647#66647
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setUseVertexAttributeAliasing and frame buffer objects not working together
I'm also having trouble with this, very frustrating. http://www.hrwallingford.com/facilities/ship-simulation-centre (http://www.hrwallingford.com/facilities/ship-simulation-centre) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=66646#66646 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Support for sampler arrays
Thanks Lionel & Seb, that's very helpful. When I tried setting ints to a Sampler2D array it said that it couldn't take ints, which is why I thought it wasn't supported. If I set to ints directly though it does work. http://www.hrwallingford.com/facilities/ship-simulation-centre (http://www.hrwallingford.com/facilities/ship-simulation-centre) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=66604#66604 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Support for sampler arrays
Thanks, I'll have to think about whether it would be feasible for me to spend time in this project altering osg core.. See i do like texture arrays, they would be ideal, except that I'm dealing with GIS data grids, so stretching/compressing them would lose information or memory space. I want to be able to store several grids of various sizes at the correct resolution, and be able to look up data from them programmatically in the shaders so I can superimpose data from one layer onto another etc. http://www.hrwallingford.com/facilities/ship-simulation-centre (http://www.hrwallingford.com/facilities/ship-simulation-centre) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=66581#66581 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Support for sampler arrays
Hi, Working on an app that is going to be doing a lot of work with large texture processing, and will need to squeeze as much data into graphics memory as possible and allow many textures to be referenced programmatically. I've got texture arrays working, but can't use this for all requirements since all layers in a texture array have to be the same size. It looks like I could use sampler arrays (e.g. sampler2D myTextures[20]; ), but osg::Uniform doesn't seem to support such a thing. I'm also wondering if there's an easy way to easily run your own OpenGL commands in case something isn't supported yet and you just want to use GL directly instead of waiting for the OSG implementation? Thank you! Cheers, Chris http://www.hrwallingford.com/facilities/ship-simulation-centre (http://www.hrwallingford.com/facilities/ship-simulation-centre) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=66577#66577 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] OpenFlight plugin update
We're at the classic commercial FOSS impasse where we both (and probably many others) would benefit from this work, but whoever pays for it to be done loses (especially if it's not accepted). There are things we need done here more urgently that don't touch on core osg/osgDB , so unfortunatly we will have to wait for this (unless someone is generous) But if I can offer any help let me know, Chris (Opinions are of course mine, not my company's) http://www.hrwallingford.com/facilities/ship-simulation-centre (http://www.hrwallingford.com/facilities/ship-simulation-centre) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=66243#66243 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Optimizing texture power of two resizing
Thanks Robert, that sounds like a better solution. http://www.hrwallingford.com/facilities/ship-simulation-centre (http://www.hrwallingford.com/facilities/ship-simulation-centre) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65885#65885 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Optimizing texture power of two resizing
Thanks Robert, that sounds like a better solution. http://www.hrwallingford.com/facilities/ship-simulation-centre (http://www.hrwallingford.com/facilities/ship-simulation-centre) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65884#65884 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Error loading OSGBs with external textures in 3.4.0
Hi Rob, Maybe you're looking at this on a mailing list? I just downloaded it successfully from the phpBB site at: http://forum.openscenegraph.org/viewtopic.php?t=15294 Let me know if that doesn't work for you and I'll put it somewhere else. Regards, Chris http://www.hrwallingford.com/facilities/ship-simulation-centre (http://www.hrwallingford.com/facilities/ship-simulation-centre) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65883#65883 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Optimizing texture power of two resizing
By the way while I have your attention is this how you would do a visitor to
access all images?
Code:
void ImageResizeVisitor::apply(osg::Node& node)
{
osg::StateSet* ss = node.getStateSet();
if ( ss )
{
osg::StateAttribute* sa =
ss->getAttribute(osg::StateAttribute::TEXTURE);
for( int j = 0; j < ss->getNumTextureAttributeLists(); j++ )
{
osg::Texture2D* tex = dynamic_cast(
ss->getTextureAttribute(j, osg::StateAttribute::TEXTURE) );
if( tex )
{
for(int i = 0; i < tex->getNumImages(); i++)
{
osg::Image* im = tex->getImage(i);
It works but took quite a while to tease the images out.
http://www.hrwallingford.com/facilities/ship-simulation-centre
(http://www.hrwallingford.com/facilities/ship-simulation-centre)
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65887#65887
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Optimizing texture power of two resizing
Hi, We've had some troubles with stuttering when going from one screen to another, and a big part of the problem seems to be that we have textures that aren't to the power of two and need to be resized. This resize happens right at the last minute before the data is sent to the graphics card, and it happens every time the texture needs to be reloaded. I hacked osg/Image.cpp Image::setImage so that images are resized as they are loaded instead, but I had to set it to only resize images with a width above 50 so that it doesn't resize font textures, which causes an exception. This does seem to be having a positive effect and working fine, but it also feels like a hack. I'm wondering how would someone who knows OSG well do this? Or if there's some other alternative I haven't thought of? (Resizing all the textures offline would be ideal, but would take too long given the amount of models we use and import) Thank you! Cheers, Chris http://www.hrwallingford.com/facilities/ship-simulation-centre (http://www.hrwallingford.com/facilities/ship-simulation-centre) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65877#65877 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Error loading OSGBs with external textures in 3.4.0
Just bumping this; anyone know what this change was about? I know we're going to have this issue and have to remember to reapply the fix when we next upgrade. http://www.hrwallingford.com/facilities/ship-simulation-centre (http://www.hrwallingford.com/facilities/ship-simulation-centre) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65878#65878 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] OpenFlight plugin update
Hi, Here is a screenshot which shows the bump map capability we're interested in, but really what it does it let you set up a bunch of parameters and textures which can be sent to your shaders. This way you can do modern rendering effects from your FLTs: [Image: http://i59.tinypic.com/2hqtdg4.jpg ] [Image: http://i58.tinypic.com/2usfpz6.jpg ] [Image: http://i59.tinypic.com/a9w9e8.png ] At the moment I've got it loading in these new opcodes but I'm not doing anything with the data. I guess if it gets rejected I can always fork then, but it would be nicer to have some idea of the requirements for it to be accepted so I know whether I should aim for a custom fork or aim for acceptance. Chris http://www.hrwallingford.com/facilities/ship-simulation-centre (http://www.hrwallingford.com/facilities/ship-simulation-centre) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65250#65250 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPlugins] OpenFlight plugin update
Hi, I've started writing an update to the OpenFlight plugin to support the "extended material" options in Creator, mainly so we can use the auto-generated bump-map textures in our shaders. I don't want to have to redo it every time there's an OSG update though, so I'm wondering what the process is for submitting updates, and whether I can submit partial support for the new options or if it must be complete? (Since there's quite a lot to these extended materials and I'm mainly interested in certain aspects) There are basically about 10 new opcodes / records, which affect the osg::Material and osg::StateSets that are generated as part of the FLT's material palette. There are also other features introduced between now and 2009, when the last update happened, that I'm not interested in. Will it be okay for me to add in targeted support for the specific things we're interested in supporting? Or would this not get in and we should fork our own custom plugin? Thank you! Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65247#65247 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture2DArray and invalid enumerant error
It'd be good to resolve this, I just spent half a day tracking this issue down. I eventually dug down to the error coming after glEnable(35866) was set, which is GL_TEXTURE_2D_ARRAY_EXT, and then coming to this. If setTextureAttributeAndModes could just detect a Texture2DArray StateAttribute it could give a warning and save a lot of trouble. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64094#64094 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
