Re: [osg-users] Help: can the location of the fragments of the image rendered by OpenGL pipeline be changed arbitrarily?
Hi, Like Chris Hanson said, you will need to use the new image write features and that would require writing to a different texture than the one that is currently bound to the camera. You could consider using a compute shader for this instead. Have a look at the osgcompute example. You can see how to use the imageStore GLSL function there. Cheers, Michael -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=60839#60839 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] The benefits of the multithreaded modes or the lack thereof
Hi, There is this thing with the otherwise fantastic OpenSceneGraph that has been bothering me for some time and that is the relative ease with which I seem to lose the benefit of multithreaded rendering and how hard it is to fix. Our application runs with the default DrawThreadPerContext threading model, but a quick look at the stats view reveals that all stages are running in sequence. There is no overlap of draw with the next frame's update/cull as expected and so the application performs the same as if it was running single threaded (which a switch to single threaded mode also confirms). Now the reason for this is that the last entry to be drawn has ended up as being marked dynamic by OSG and therefore the entire draw stage needs to finish before the update thread can be unlocked. This is by design and I understand the reasoning behind it. In our case it turned out to be Wang Rui's EffectCompositor (which is also otherwise a great tool for post-processing). It uses a quad that is repeatedly rendered for each of the post-processing stages and that quad was the last to render. Even though the quad itself was not marked dynamic it was still sitting in a render leaf that was marked dynamic and I don't know why. My point is that I think it is easy to accidentally get into this situation and thereby lose the performance benefits that the multithreaded modes are supposed to provide. My questions are: How do you avoid this situation (if possible) and how do you identify the offending part of the scene graph if it has happened? Thank you! Cheers, Michael -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=58033#58033 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Bug in initial renderer compile?
Hi, During development of a new shader-based point-rendering system I started getting INVALID_OPERATION at start of State::apply(StateSet*) for the first rendered frame (subsequent frames are OK). The scene consists of a geode, shapedrawable box (no stateset/fixed function pipeline) and the point rendering node (shader pipeline) both under the same parent group. When rendering, the box is drawn before the points. It turned out to be due to my point shader being active for the box. The shader becomes active (by mistake?) as a result of the renderer calling compile(). Adding a stateset to the box node with an empty program fixes the issue since it forces fixed function into effect before drawing the box. It would be nice to avoid this initial INVALID_OPERATION message. Has anyone else encountered this or something similar? It looks like a bug to me. What do you think? Thank you! Cheers, Michael -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57951#57951 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in initial renderer compile?
Hi Robert and Nick,
It does very much look like a missing cleanup after compilation.
The following things need to be present:
- a geometry shader
- a uniform
- rendering the node using the above after an object that is not compatible
with the shader program.
I have attached a modified version of osgshape.cpp that causes the failure.
Thank you for looking into it!
Cheers,
Michael
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=57961#57961
/* OpenSceneGraph example, osgshape.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include osg/Geode
#include osg/ShapeDrawable
#include osg/Material
#include osg/Texture2D
#include osgUtil/ShaderGen
#include osgViewer/Viewer
#include osgDB/ReadFile
#include osgDB/WriteFile
#include osg/Math
#include GL/glext.h
// for the grid data..
#include ../osghangglide/terrain_coords.h
osg::Geode* createShapes()
{
osg::Geode* geode = new osg::Geode();
// ---
// Set up a StateSet to texture the objects
// ---
osg::StateSet* stateset = new osg::StateSet();
osg::Image* image = osgDB::readImageFile( Images/lz.rgb );
if (image)
{
osg::Texture2D* texture = new osg::Texture2D;
texture-setImage(image);
texture-setFilter(osg::Texture::MIN_FILTER, osg::Texture::LINEAR);
stateset-setTextureAttributeAndModes(0,texture,
osg::StateAttribute::ON);
}
stateset-setMode(GL_LIGHTING, osg::StateAttribute::ON);
geode-setStateSet( stateset );
float radius = 0.8f;
float height = 1.0f;
osg::TessellationHints* hints = new osg::TessellationHints;
hints-setDetailRatio(0.5f);
geode-addDrawable(new osg::ShapeDrawable(new
osg::Sphere(osg::Vec3(0.0f,0.0f,0.0f),radius),hints));
geode-addDrawable(new osg::ShapeDrawable(new
osg::Box(osg::Vec3(2.0f,0.0f,0.0f),2*radius),hints));
geode-addDrawable(new osg::ShapeDrawable(new
osg::Cone(osg::Vec3(4.0f,0.0f,0.0f),radius,height),hints));
geode-addDrawable(new osg::ShapeDrawable(new
osg::Cylinder(osg::Vec3(6.0f,0.0f,0.0f),radius,height),hints));
geode-addDrawable(new osg::ShapeDrawable(new
osg::Capsule(osg::Vec3(8.0f,0.0f,0.0f),radius,height),hints));
osg::HeightField* grid = new osg::HeightField;
grid-allocate(38,39);
grid-setXInterval(0.28f);
grid-setYInterval(0.28f);
for(unsigned int r=0;r39;++r)
{
for(unsigned int c=0;c38;++c)
{
grid-setHeight(c,r,vertex[r+c*39][2]);
}
}
geode-addDrawable(new osg::ShapeDrawable(grid));
osg::ConvexHull* mesh = new osg::ConvexHull;
osg::Vec3Array* vertices = new osg::Vec3Array(4);
(*vertices)[0].set(9.0+0.0f,-1.0f+2.0f,-1.0f+0.0f);
(*vertices)[1].set(9.0+1.0f,-1.0f+0.0f,-1.0f+0.0f);
(*vertices)[2].set(9.0+2.0f,-1.0f+2.0f,-1.0f+0.0f);
(*vertices)[3].set(9.0+1.0f,-1.0f+1.0f,-1.0f+2.0f);
osg::UByteArray* indices = new osg::UByteArray(12);
(*indices)[0]=0;
(*indices)[1]=2;
(*indices)[2]=1;
(*indices)[3]=0;
(*indices)[4]=1;
(*indices)[5]=3;
(*indices)[6]=1;
(*indices)[7]=2;
(*indices)[8]=3;
(*indices)[9]=2;
(*indices)[10]=0;
(*indices)[11]=3;
mesh-setVertices(vertices);
mesh-setIndices(indices);
geode-addDrawable(new osg::ShapeDrawable(mesh));
return geode;
}
static const GLuint PIXELSIZE_BINDATTRIB_LOCATION = osg::Drawable::ATTRIBUTE_6;
osg::Program* createPointShader()
{
static const char* vertSource =
{
#version 120\n
\n
varying vec4 color;\n
\n
void main(void)\n
{\n
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;\n
gl_PointSize = 30.0;\n
color = gl_Color;\n
}\n
};
static const char* geomSource =
{
#version 330 core\n
\n
uniform float minPixelSize;\n
\n
layout (points) in;\n
in vec4 color[];\n
\n
layout (points, max_vertices = 1)
Re: [osg-users] Bug in initial renderer compile?
Hi again, I should mention that I am currently on OpenSceneGraph 3.1.4. :-) Michael -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57962#57962 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Using integer format textures in an FBO attachment
Hi,
I'm having trouble attaching integer format textures to an FBO camera. The
following code:
Code:
#include stdafx.h
#include osgViewer/Viewer
#include osg/Texture2D
int main(int argc, char* argv[])
{
osg::ref_ptrosg::Texture2D targetTex = new osg::Texture2D;
targetTex-setTextureSize(800, 600);
targetTex-setFilter(osg::Texture2D::MIN_FILTER, osg::Texture2D::NEAREST);
targetTex-setFilter(osg::Texture2D::MAG_FILTER, osg::Texture2D::NEAREST);
targetTex-setInternalFormat(GL_R32UI);
targetTex-setSourceFormat(GL_RED);
targetTex-setSourceType(GL_UNSIGNED_INT);
osg::Camera* rttCamera = new osg::Camera;
rttCamera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
rttCamera-attach(osg::Camera::COLOR_BUFFER, targetTex);
osgViewer::Viewer viewer;
viewer.setSceneData(rttCamera);
return viewer.run();
}
will produce:
Code:
RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cd6
Warning: detected OpenGL error 'invalid operation' at start of State::apply()
RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cd6
If I replace the format selection lines with:
Code:
targetTex-setInternalFormat(GL_R32F);
targetTex-setSourceFormat(GL_RED);
targetTex-setSourceType(GL_FLOAT);
everything returns to normal (no errors).
Am I missing something obvious? I am using version 3.1.4 and I have a GTX 480
with OpenGL 4.3 driver support (I have compute shaders working, so I should be
relatively up to speed!).
Thank you!
Cheers,
Michael
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=53878#53878
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Reading from a texture in a compute shader
Hi, Robert Thank you! I will give it a try. Cheers, Michael -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=53521#53521 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Reading from a texture in a compute shader
Hi again, Robert That did the trick! I moved applyModeList and applyAttributeList down right before if(_shaderCompositionEnabled). I don't know if it produces any side effects. I tried running my application on top of the change and didn't notice anything. It uses osgEarth and Wang Rui's EffectCompositor and renders in HDR and also has a few 3D models loaded, so I would say that a fair deal of the code has been exercised. If you don't have any objections I will make a submission. Thank you again. Cheers, Michael -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=53525#53525 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Reading from a texture in a compute shader
I have digged into this a little further and using glIntercept I learned that glDispatchCompute ends up being executed before the flowers texture has been bound. Adding a second quad to the scene with the flowers texture on texture unit 1 before the compute node fixes the problem, but is hardly ideal. Is OSG delaying texture switches until it sees actual geometry somehow? If that is the case, then some sort of check for compute shaders might need to be added so that texture attributes on the path to a compute program are executed before glDispatchCompute. Can someone perhaps point me in the right direction on how to fix this or maybe suggest a better solution? I am on 3.1.4, btw and it doesn't look like there have been any changes to compute shaders since its release. Cheers, Michael P.S.: I would like to use this for a histogram compute pass using Wang Rui's excellent EffectCompositor, which I have altered a bit to get compute shader support. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=53512#53512 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Reading from a texture in a compute shader
Hi,
I am trying to implement a histogram using the new compute shader support, but
I don't seem to be able to read from a texture. I am new to compute shaders, so
I might be missing something obvious.
I have attached a modified version of the osgcomputeshaders.cpp file in which I
simply load the blueFlowers.png file from the OSG data set, then compute the
intensity of each pixel and write it to targetTex.
The image comes out black, though.
Am I missing something?
Thank you!
Cheers,
Michael
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=53500#53500
/* -*-c++-*- OpenSceneGraph example, osgcomputeshaders.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
// Written by Wang Rui
// This example can work only if GL version is 4.3 or greater
#include osg/Texture2D
#include osg/Geometry
#include osg/Geode
#include osgDB/ReadFile
#include osgGA/StateSetManipulator
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
static char* computeSrc = {
#version 430\n
uniform image2D targetTex;\n
uniform sampler2D flowersTexture;\n
layout (local_size_x = 16, local_size_y = 16) in;\n
void main() {\n
ivec2 storePos = ivec2(gl_GlobalInvocationID.xy);\n
vec4 c = texture2D(flowersTexture, vec2(storePos) / vec2(512,512));\n
float L = 0.2126 * c.r + 0.7152 * c.g + 0.0722 * c.b;\n
imageStore(targetTex, storePos, vec4(L, 0.0, 0.0, 0.0));\n
}\n
};
int main( int argc, char** argv )
{
osg::ArgumentParser arguments( argc, argv );
osg::ref_ptrosg::Texture2D flowersTexture = new
osg::Texture2D(osgDB::readImageFile(Images/blueFlowers.png));
//flowersTexture-bindToImageUnit(1, osg::Texture::READ_ONLY, GL_RGBA8);
// Create the texture as both the output of compute shader and the input of
a normal quad
osg::ref_ptrosg::Texture2D tex2D = new osg::Texture2D;
tex2D-setTextureSize( 512, 512 );
tex2D-setFilter( osg::Texture2D::MIN_FILTER, osg::Texture2D::LINEAR );
tex2D-setFilter( osg::Texture2D::MAG_FILTER, osg::Texture2D::LINEAR );
tex2D-setInternalFormat( GL_R32F );
tex2D-setSourceFormat( GL_RED );
tex2D-setSourceType( GL_FLOAT );
tex2D-bindToImageUnit( 0, osg::Texture::WRITE_ONLY ); // So we can use
'image2D' in the compute shader
// The compute shader can't work with other kinds of shaders
// It also requires the work group numbers. Setting them to 0 will disable
the compute shader
osg::ref_ptrosg::Program computeProg = new osg::Program;
computeProg-setComputeGroups( 512/16, 512/16, 1 );
computeProg-addShader( new osg::Shader(osg::Shader::COMPUTE, computeSrc) );
// Create a node for outputting to the texture.
// It is OK to have just an empty node here, but seems inbuilt uniforms
like osg_FrameTime won't work then.
// TODO: maybe we can have a custom drawable which also will implement
glMemoryBarrier?
osg::Node* sourceNode = osgDB::readNodeFile(axes.osgt);
if ( !sourceNode ) sourceNode = new osg::Node;
sourceNode-setDataVariance( osg::Object::DYNAMIC );
sourceNode-getOrCreateStateSet()-setAttributeAndModes( computeProg.get()
);
sourceNode-getOrCreateStateSet()-addUniform( new
osg::Uniform(targetTex, (int)0) );
sourceNode-getOrCreateStateSet()-addUniform( new
osg::Uniform(flowersTexture, (int)1) );
sourceNode-getOrCreateStateSet()-setTextureAttributeAndModes( 0,
tex2D.get() );
sourceNode-getOrCreateStateSet()-setTextureAttributeAndModes( 1,
flowersTexture.get() );
// Display the texture on a quad. We will also be able to operate on the
data if reading back to CPU side
osg::Geometry* geom = osg::createTexturedQuadGeometry(
osg::Vec3(), osg::Vec3(1.0f,0.0f,0.0f), osg::Vec3(0.0f,0.0f,1.0f) );
osg::ref_ptrosg::Geode quad = new osg::Geode;
quad-addDrawable( geom );
quad-getOrCreateStateSet()-setMode( GL_LIGHTING, osg::StateAttribute::OFF
);
quad-getOrCreateStateSet()-setTextureAttributeAndModes( 0, tex2D.get() );
// Create the scene graph and start the viewer
Re: [osg-users] [3rdparty] SpeedTree 6.0 integration
Hi, hybr Thank you! I hadn't thought of the view and projection matrices - I was focused on still active shader programs (which I later ruled out, though). Also, I will try gDebugger to see if that can shed some light on the issue. Cheers, Michael -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45334#45334 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [3rdparty] SpeedTree 6.0 integration
Hi, everyone! Like others before us, we are trying to integrate SpeedTree into our OpenSceneGraph-based application and are having some trouble. We are using the custum-drawable approach and the trees are (finally) rendering fine. The problem is that, although simple objects like cow.osg render ok, paged terrains do not. Neither does the stats view. I think I have tried every imaginable combination of glDisable and state dirtying function there is without luck. I have attached a picture of the way it looks atm. Does anyone have a clue as to what might be wrong? Those lines protruding from the center is the terrain! Thank you! Cheers, Michael -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45191#45191 Attachments: http://forum.openscenegraph.org//files/osgspeedtree_164.jpg ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Databasepager + multiple views + different camera positions = memory leak?
Hi, Robert! You are free to use my code as you wish :-) Do I need to download anything extra wrt the earth.ive you linked to? It does not contain any PagedLOD nodes (at least the statistics view does not report any), and so will not have any issues. Thanks for looking into the issue and thanks for a great scene graph, btw! Cheers, Michael -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=20321#20321 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Databasepager + multiple views + different camera positions = memory leak?
Hi everyone! This is a tough one. I'm now certain that there is more than one bug at large here! At least one in the pager (the one mentioned in the PagedLOD experts thread) and at least one in the txp plugin. The one I have been chasing for the past 2 days is within the txp plugin and looks more like a design issue than a bug. I don't think the txp plugin was designed with multiple cameras in mind! The TXPNode (the top level node when loading a .txp archive) updates the camera position in _pageManager on every cull visit (through updateEye). Since there is one cull visit per camera per frame, the page manager position jumps between multiple positions every frame. Every time the position changes, the set of LOD0 nodes is reconsidered. This results in multiple cameras fighting over which set of LOD0 nodes should be present. Note that LOD0 nodes, or blocks, become children of the TXPNode in the update stage. At some point, a state is achieved in which a certain number of nodes end up on the _nodesToAdd list and the same amount of nodes end up on the _nodesToRemove list. Unfortunately, some of the nodes on the remove list are not actually in the _children list, so the net result is that more nodes are added than removed. This happens every frame, so the number of children of the TXPNode increases indefinitely. Since these children are PagedLOD nodes, they, in turn, also start loading in children until all memory is exhausted. It seems to me as though a major overhaul is needed for the txp plugin to be able to handle multiple cameras. As I mentioned earlier, one workaround is to make sure that each TXPNode is only visited by one camera - for instance by loading the terrain anew for each camera. Cheers, Michael [/list] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19476#19476 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Databasepager + multiple views + different camera positions = memory leak?
Hello everyone, We are having the exact same problem at our company for quite some time (currently on osg 2.8.0 via Delta3D and using TerraPage terrains). I have verified that viewing the terrain in the osgViewer works fine, but in our app, which also uses multiple cameras, the memory-keeps-growing-until-crash issue occurs when the cameras are not looking at the exact same thing (have the same projection and view matrices with the same LOD scale). The more different they are, the easier it is to trigger the issue, it seems. What we did to work around the issue, is to make sure that no two cameras in the graph render the same PagedLOD node. That is, we load the terrain multiple times using osgDB::readNodeFile and point each camera to each instance. I hope this helps on shedding some light on what is going on. Additional info: Delta3D design currently limits OSG to single-threaded mode. I am on WindowsXP, using an NVidia card, not that I think that makes a difference. I also seem to recall, that the active lod node list in the pager starts to grow rapidly when I put the second camera into the scene graph at runtime. Cheers, Michael -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18075#18075 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Particle system setInitialRotationalSpeedRange()
Hi all! We are having this issue as well in our simulation software, since we are also rotating our smoke particles to add a nice motion the smoke. Any idea when it will be fixed? Or does someone know of a workaround? Kind regards, Michael *** Zsa Zsa Gabor - A man in love is incomplete until he has married. Then he's finished. 2008/12/5 Michael Bach Jensen [EMAIL PROTECTED]: Hi Thom, Thanks for the detective work. The change you've suggested as causing the regression is r7961. http://www.openscenegraph.org/projects/osg/changeset/7961 It's six months since I code this so it's a bit cold a topic so off the top of my head I can't point to anything in a particular as being the cause of the problems. I will have to sit down and step through the code. Thanks for pointing out that SmokeBox.osg reproduces the problem, with the problem in front of me it's very difficult to spot issues in code. Robert. On Tue, Nov 11, 2008 at 11:21 PM, Jolley, Thomas P [EMAIL PROTECTED] wrote: Hi Robert, I've looked into this a little further. It appears the changes you made to ParticleSystem.cpp on March 17th is the reason for the behavior change. I don't have a solution yet other than backing out the changes. I'm still trying to understand what you're doing in the single_pass_render function before coming up with a solution. I think this problem was mentioned in an earlier thread around May. See http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-May/011595.html. To see the problem look at SmokeBox.osg with osgviewer (I'm using osg 2.6.0). The particles are rotating about the wrong axis (or at least a different axis). Tom Jolley From: Jolley, Thomas P Sent: Thursday, August 21, 2008 2:11 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Particle system setInitialRotationalSpeedRange() Hi Erik, I noticed the same thing about a week ago while upgrading an application from osg 1.0 to 2.4. It was on my list of things to look into. From: Erik Johnson [EMAIL PROTECTED] Sent: Thursday, August 21, 2008 10:30 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Particle system setInitialRotationalSpeedRange() There is certainly a change in behavior, although I can't pinpoint the change in code yet. Setting the rotational speed with (0, 0, 1): OSG 2.2.0 - particles rotate like fans (pinwheels) OSG 2.4.0 - particles rotate like a margarita blender (cork-screw) OSG 2.6.0 - particles rotate like a margarita blender (cork-screw) I guess I'm just wondering if this is the expected behavior? And I'm surprised nobody has a problem with this. Thanks, Erik Date: Thu, 21 Aug 2008 09:26:52 +0100 From: Robert Osfield [EMAIL PROTECTED] Subject: Re: [osg-users] Particle system setInitialRotationalSpeedRange() To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Hi Erik, osgParticle has hardly been touched between OSG-2.2 and 2.6. Use svn log to check which files have changed. Robert. On Thu, Aug 21, 2008 at 1:07 AM, Erik Johnson [EMAIL PROTECTED] wrote: Hi all, It seems to me, back in the OSG 2.2.x time frame, that I could set the initial rotational velocity of the RadialShooter and have the particles pinwheel around their center point, while maintaining their billboard orientation and face the Camera. Perhaps it was a rotation on the Y axis. Nowadays with OSG 2.4/2.6, setting the rotational speed will cause the particles to rotate relative to the world axis and not in the camera-relative axis. Is this a bug? A feature? Is it still posible to pinwheel a particle around? Does anyone use setInitialRotationalSpeedRange()? This was a cool effect which added a nice dimension to smoke plumes and such. Thanks for any info! -Erik Johnson ___ 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 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] Particle system setInitialRotationalSpeedRange()
Hi all! Does anyone know if the bug mentioned in the following post will be fixed or if there is a workaround? http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg18069.html We use it, like Erik Johnson mentioned, to create a nice motion to smoke effects. /Michael *** Steve Martin - I've got to keep breathing. It'll be my worst business mistake if I don't. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Dramatic increase in event traversal time during mouse movement
Hello, group! I was looking at the nice statshandler graphics in osgViewer.exe, and noticed a dramatic increase in the time spent in the event traversal stage when the mouse was moved (goes from 0.02ms to around 8ms). Strangely enough, rotating the view by dragging with the mouse, almost does not increase the event traversal time (goes to 0.04ms). Has anyone else noticed this behavior and have an idea on whats going on? I am working on project in Delta3D and first noticed it there, but since the same happens in osgViewer.exe on a separate installation, I thought I'd ask here! I am on Windows XP and was looking at the cow, btw! Sincerely, Michael ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
