Re: [osg-users] Render to texture 3D
Hi Julien,
It's me that submitted this change at
http://www.mail-archive.com/osg-submissions@lists.openscenegraph.org/msg05568.html
It's hard to tell what's going wrong without the full code of your camera setup.
In http://www.opengl.org/registry/specs/ARB/geometry_shader4.txt
error 0x8da8 refers to FRAMEBUFFER_INCOMPLETE_LAYER_TARGETS_ARB and the
document has possible cause for this error.
Regards,
-Fred
- Julien Valentin a écrit :
Hi,
I'm trying to make efficient fluid simulation with osg
I've just found this page :
http://www.mail-archive.com//msg05568.html
It look pretty great as my 1 camera per slice code is very CPU time
consuming.
I develop a geometry shader that change gl_layer value per primitive.
It work so i change my texture my texture attachement to camera's FBO
as follow:
Code:
for(int i=0;i_depth;i++){
//one cam per slice
_cameras[i]-attach( osg::Camera::COLOR_BUFFER,tex,0,i,false);
}
to
for(int i=0;i1;i++){
//one overalll camera
_cameras[0]-attach(
osg::Camera::COLOR_BUFFER,tex,0,osg::Camera::FACE_CONTROLLED_BY_GEOMETRY_SHADER);
}
But this change make a crash:
Code:
RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8da8
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL error 'invalid enumerant' after RenderBin::draw(, )
Hello Evan, I've written a very simple application which should simply display a sphere. The code compiles, but when the viewer runs, the sphere doesn't appear and I get the message: Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,) I have no idea what this means or how to fix it. I was able to compile and run successfully on a Linux system, but I've had no luck with Windows and Visual C++. Can anybody help me out? We will not be able to help much if you don't show your code, because what you describe is very simple and should work (at least as far as we can see from your description). If we see the code we might be able to tell you what's wrong. Also, have you looked at the OSG examples and the Getting Started Guide to make sure you're doing things right? J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [ANN] MS Kinect - official drivers available
It runs on Linux and Windows, but OpenNI and hence the modified driver doesn't support Mac OS yet. Christian. On Sat, Dec 18, 2010 at 10:05 PM, Torben Dannhauer tor...@dannhauer.info wrote: Hi Jan, I agree. Here is the journal article I talkes about http://www.heise.de/open/meldung/Offizielle-Open-Source-Treiber-fuer-Kinect-1152510.html This is the article translated by google: http://translate.google.com/translate?u=http%3A%2F%2Fwww.heise.de%2Fopen%2Fmeldung%2FOffizielle-Open-Source-Treiber-fuer-Kinect-1152510.htmlsl=detl=enhl=deie=UTF-8 Does the non-openNI Driver work on win, Linux and Mac? Best regards, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34964#34964 ___ 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] Problem with Transparency when using osg::Cameras
Hello all, I have a problem regarding transparency and osg::Cameras. Because my main graph is very complex I will describe here a simplified version of the graph that produces the problem. What I want as a result is three colored spheres. The middle should be opaque and the left and right should be transparent. And I do it like this: I have a main root osg::Group node with two child osg::Group nodes. At the first one's StateSet I set the rendering hint to StateSet::TRANSPARENT_BIN. Then I just attach to it two osg::Geodes. At the second one I add as a child an osg::Camera and then I attach a osg::Geode on the camera. Take a look at the diagram picture to understand my graph. The result I get is really strange and not the expected of course. I can not see the middle sphere through the transparent ones but I can see a transparent sphere through the other transparent one. Even if the middle opaque sphere is between them. (I can't see the opaque one at all through the transparent spheres) Take a look at the picture to understand the exact problem. Looks like the osg::Camera somehow breaks the rendering order. Now, the strange thing is that IF I use a osg::Group instead of the osg::Camera, then everything works! Any idea why is this happening? I have also attached my source code which is also available at this site: http://pastesite.com/20775 Thanks for your time guys! Cheers, George -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34997#34997 Attachments: http://forum.openscenegraph.org//files/main_184.cpp http://forum.openscenegraph.org//files/transparencyprobem_100.png http://forum.openscenegraph.org//files/osggraphsm_134.png ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cutting geometry out of a scene
Hi Kevin, I don't know if this can be useful for you or not, but you may look at osgSim::CustomPolytope or its remote derivative osgShadow::ConvexPolyhedron. These classes supoport tranformation and cut with other polytopes. Both classes keep reference points for each of the polytope faces. These points basically represent polygons on each of planes of convex polytope. Both classes don't keep other attributes beyound x,y,z vertex coords but it would be straightforward to extend their storage and methods so that they keep more than 3 coordinates per reference point. Cheers, Wojtek Lewandowski -Original Message- From: Paul Martz Sent: Sunday, December 19, 2010 8:41 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Cutting geometry out of a scene On 12/19/2010 12:01 PM, Kevin Bentley wrote: Hi, I'm writing an app that essentially needs to 'cut' some geometry and its textures from a scene, to create a new model. Currently I'm using a PolytopeIntersector to find the faces I'm interested in. The next step is that I need to clip those faces to the boundaries of the Polytope I used to find the intersection. I also need to add some vertices to some of the faces to slightly change the shape. I've been looking at some libraries for geometry operations. I want to preserve the texture mapping if I divide the faces up, and I haven't found a library that I can use to divide the faces and preserve the texture mapping (creating new texture coordinates for the new verts). What I'm wondering is if there is something in OSG already I should be looking at as an example of this type of problem, or if anyone has any hints as to the best way to approach this. I sometimes find myself going down a path to solve a problem the hard way in OSG, then later I find out there's some existing feature I should have used to make life easier. Any tips are very much appreciated! I don't know of an existing OSG-compatible tool for this, but it shouldn't be difficult to implement. Clipping a triangle against a plane is fairly trivial and it sounds like you've already solved that. Use linear interpolation to derive the new texture coordinate; that's what OpenGL does when it clips primitives. -Paul ___ 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] Problem with Transparency when using osg::Cameras
I'm not sure why you think you should use a Camera as you describe, it seems like a misuse of the Camera class, which is intended for a complete frame rendering, and not for combining with data from other Cameras, which is what you have here (osgViewer / SceneView uses a Camera implicitly, above your root node). That's not to say that you can't combine the renderings of two Cameras into a single frame; you can. But you need to be very aware of what OSG is doing for each Camera, and configure them to work together with respect to rendering order, clearing, etc. You've already discovered that eliminating the Camera resolves the issue. This seems to be a clear case of, if it hurts, don't do it. -Paul On 12/20/2010 8:48 AM, George Bekos wrote: Hello all, I have a problem regarding transparency and osg::Cameras. Because my main graph is very complex I will describe here a simplified version of the graph that produces the problem. What I want as a result is three colored spheres. The middle should be opaque and the left and right should be transparent. And I do it like this: I have a main root osg::Group node with two child osg::Group nodes. At the first one's StateSet I set the rendering hint to StateSet::TRANSPARENT_BIN. Then I just attach to it two osg::Geodes. At the second one I add as a child an osg::Camera and then I attach a osg::Geode on the camera. Take a look at the diagram picture to understand my graph. The result I get is really strange and not the expected of course. I can not see the middle sphere through the transparent ones but I can see a transparent sphere through the other transparent one. Even if the middle opaque sphere is between them. (I can't see the opaque one at all through the transparent spheres) Take a look at the picture to understand the exact problem. Looks like the osg::Camera somehow breaks the rendering order. Now, the strange thing is that IF I use a osg::Group instead of the osg::Camera, then everything works! Any idea why is this happening? I have also attached my source code which is also available at this site: http://pastesite.com/20775 Thanks for your time guys! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL error 'invalid enumerant' after RenderBin::draw(, )
Skylark wrote:
Hello Evan,
We will not be able to help much if you don't show your code, because
what you describe is very simple and should work (at least as far as we
can see from your description). If we see the code we might be able to
tell you what's wrong.
Also, have you looked at the OSG examples and the Getting Started Guide
to make sure you're doing things right?
J-S
--
--
Post generated by Mail2Forum
Hello,
Yes, I followed the startup guide to get OSG working on my computer. This is
the simple code that I was trying:
Code:
#include osg/Group
#include osg/LightSource
#include osg/ShapeDrawable
#include osgViewer/Viewer
using namespace osg;
// main function
int main()
{
// create the root node of the scene graph
ref_ptrGroup root = new Group;
// create a node to the geometry of a spherical object
ref_ptrGeode ballNode = new Geode;
ballNode-addDrawable(new ShapeDrawable(new Sphere));
// create a distant light, with 0 for the homogeneous coord
Vec4 lightDirection(1, -1, 1, 0);
ref_ptrLightSource ls = new LightSource;
ls-getLight()-setPosition(lightDirection);
// set the intensity properties for the light
ls-getLight()-setAmbient(Vec4(0.2, 0.2, 0.2, 1.0));
ls-getLight()-setDiffuse(Vec4(1.0, 1.0, 0.7, 1.0));
ls-getLight()-setSpecular(Vec4(1.0, 0, 0, 1.0));
// assemble the node hierarchy
root-addChild(ls.get());
root-addChild(ballNode.get());
// create the viewer helper object
osgViewer::Viewer viewer;
viewer.setSceneData(root.get());
viewer.realize();
while( !viewer.done() )
{
viewer.frame();
}
return 0;
}
Thanks in advance for your help.
~Evan
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=35003#35003
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] FLT test suite updated
Hi, to all of you doing FLT work -- I've updated the top-level CMakeLists.txt file in the FLT regression test suite: http://code.google.com/p/osgfltexport/ CMake now enforces finding both Python and PIL and doesn't generate project files if not found. This should eliminate the possibility of running the test suite without these required dependencies. If you are able to generate project files in CMake, and (when running the tests) you are still seeing all tests fail, then we can assume that PIL is working properly and the problem must be elsewhere. Let me know if you encounter any issues with these changes. -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL error 'invalid enumerant' after RenderBin::draw(, )
Hello Evan, The default viewer camera position is at (0,0,0), which turns out to be inside your sphere. So you just see the inside of your sphere (not a very interesting view point to be sure! :-) ). You have used the while(!viewer.done()) viewer.frame() method of coding the main loop, and so no camera manipulator is created automatically by the viewer, and you don't add any camera manipulator yourself, so you will need to set the viewer camera's view matrix yourself to be able to see the object. Add viewer.getCamera()-setViewMatrixAsLookAt(osg::Vec3(0,-10,0), osg::Vec3(0,0,0), osg::Vec3(0,0,1)); just before your frame loop to see the object. You can also call this method at different times inside the frame loop (or in callbacks) if you want to animate the camera's position. You could also opt to add a camera manipulator, then you would add viewer.setCameraManipulator(new osgGA::TrackballManipulator); before your frame loop, for example. The camera manipulator will center on your scene's bounds on the first frame, so you will see the whole scene and will be able to move/rotate the camera around. With either of these changes I can see the sphere just fine (and with the correct yellowish lighting as you've set in your light source's diffuse light color). Of course without a camera manipulator you won't be able to rotate the camera with the mouse (unless you code that yourself in an event handler that sets the camera's view matrix, for example). As for your OpenGL messages, I don't get any of those when running your code. They could be related to your driver. These messages are sometimes false positives, meaning they may be shown even if nothing is wrong. I would recommend checking if there is an updated driver for your video card and see if they go away. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fullscreen dual monitor spanning
robertosfield wrote: This sounds like the X11 redirect to the X11 window manager that is deciding for you that the window is too big and knows better. The Traits::overrideRedirect as I mentioned earlier in this thread is what should address this. Robert. ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum Greetings Robert! Actually what was going on is that I was not using the Traits correctly. Once I was able to figure that out I hard coded the size to what I knew what the screen was and was able to take over both screens with one slave camera. Then I added another slave camera and set one for one screen and the other camera for the other screen. Then reposition the cameras at the right eye distance and proper rotation from each other so it can appear as a natural stereo vision. Then, all I needed to was run the correct screen to the right polarized projector, fine adjust the eye distance and stuff and I got the Cessna aircraft appearing in a real time Real3D pesentation. D Glenn D Glenn (a.k.a David Glenn) - Moving Heaven and Earth! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35006#35006 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] OpenFlight Export - MultiTexturing - wrong Texture Coordinates
On 12/17/2010 9:13 AM, Katharina Plugge wrote: Hi, MultiTexturing has still its problems. Now I tried the first time to use up to 3 textures. Converting to flt again lead to corrupted texture coords. I attached an osg-file which can be used to reproduce the problem. Converting this file to flt shows the effect. Unfortunatly this time I have no idea what goes wrong. In FltExportVisitor::writeUVList the texture coords for both channels are determined correctly and written to _records. Somehow the texture coordinates have to be corrupted later. In the resulting file texture coords from channel one are mixed up with those from channel 2 and vice versa. Would be great, if someone could help here. Thank you! I think I've identified the problem. in expGeometryRecords.cpp lines 813-820, we write the UV list data incorrectly. According to the FLT spec, the data should be grouped per-vertex, not per-layer. We should have: UV for vertex 0, layer 1 UV for vertex 0, layer 2 UV for vertex 1, layer 1 UV for vertex 1, layer 2 ...etc... Instead, we have this: UV for vertex 0, layer 1 UV for vertex 1, layer 1 ...etc... UV for vertex 0, layer 2 UV for vertex 1, layer 2 ...etc... Oops! I'll commit a fix shortly (if Robert has granted me write permission, otherwise I'll post to osg-submissions). I'll also add your test case to the regression suite. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] OpenFlight Export - MultiTexturing - wrong Texture Coordinates
Hi Robert Jose -- Apparently, I still don't have write permission for the
OpenFlight plugin. Please commit this change to resolve Katharina's problem. Thanks.
-Paul
On 12/20/2010 1:56 PM, Paul Martz wrote:
On 12/17/2010 9:13 AM, Katharina Plugge wrote:
Hi,
MultiTexturing has still its problems. Now I tried the first time to use up to
3 textures. Converting to flt again lead to corrupted texture coords. I
attached an osg-file which can be used to reproduce the problem. Converting
this file to flt shows the effect.
Unfortunatly this time I have no idea what goes wrong. In
FltExportVisitor::writeUVList the texture coords for both channels are
determined correctly and written to _records. Somehow the texture coordinates
have to be corrupted later. In the resulting file texture coords from channel
one are mixed up with those from channel 2 and vice versa.
Would be great, if someone could help here.
Thank you!
I think I've identified the problem.
in expGeometryRecords.cpp lines 813-820, we write the UV list data incorrectly.
According to the FLT spec, the data should be grouped per-vertex, not per-layer.
We should have:
UV for vertex 0, layer 1
UV for vertex 0, layer 2
UV for vertex 1, layer 1
UV for vertex 1, layer 2
...etc...
Instead, we have this:
UV for vertex 0, layer 1
UV for vertex 1, layer 1
...etc...
UV for vertex 0, layer 2
UV for vertex 1, layer 2
...etc...
Oops!
I'll commit a fix shortly (if Robert has granted me write permission, otherwise
I'll post to osg-submissions).
I'll also add your test case to the regression suite.
-Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
-Paul Martz Skew Matrix Software
http://www.skew-matrix.com/
/*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or (at
* your option) any later version. The full license is in the LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library 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. See the
* OpenSceneGraph Public License for more details.
*/
//
// Copyright(c) 2008 Skew Matrix Software LLC.
//
#include FltExportVisitor.h
#include DataOutputStream.h
#include Opcodes.h
#include MaterialPaletteManager.h
#include TexturePaletteManager.h
#include VertexPaletteManager.h
#include osg/CullFace
#include osg/BlendFunc
#include osg/Geometry
#include osg/Geode
#include osg/Billboard
#include osg/io_utils
#include osg/Material
#include osg/Texture2D
#include sstream
namespace flt
{
// Bit flags for multitexturing
static unsigned int LAYER_1( 0x8000 0 );
#if 0
// unused so if'deffing out
static unsigned int LAYER_2( 0x8000 1 );
static unsigned int LAYER_3( 0x8000 2 );
static unsigned int LAYER_4( 0x8000 3 );
static unsigned int LAYER_5( 0x8000 4 );
static unsigned int LAYER_6( 0x8000 5 );
static unsigned int LAYER_7( 0x8000 6 );
#endif
bool
FltExportVisitor::isLit( const osg::Geometry geom ) const
{
const osg::StateSet* ss = getCurrentStateSet();
if ( ss-getMode( GL_LIGHTING ) osg::StateAttribute::ON )
return true;
else
return false; //( geom.getNormalBinding() ==
osg::Geometry::BIND_PER_VERTEX );
}
bool
FltExportVisitor::isTextured( int unit, const osg::Geometry geom ) const
{
const osg::StateSet* ss = getCurrentStateSet();
bool texOn( ss-getTextureMode( unit, GL_TEXTURE_2D )
osg::StateAttribute::ON );
bool hasCoords( geom.getTexCoordArray( unit ) != NULL );
return( texOn hasCoords );
}
bool
FltExportVisitor::isMesh( const GLenum mode ) const
{
return( (mode == GL_TRIANGLE_STRIP) ||
(mode == GL_TRIANGLE_FAN) ||
(mode == GL_QUAD_STRIP) );
}
bool
FltExportVisitor::atLeastOneFace( const osg::Geometry geom ) const
{
// Return true if at least one PrimitiveSet mode will use a Face record.
unsigned int jdx;
for (jdx=0; jdx geom.getNumPrimitiveSets(); jdx++)
{
const osg::PrimitiveSet* prim = geom.getPrimitiveSet( jdx );
if( !isMesh( prim-getMode() ) )
return true;
}
// All PrimitiveSet modes will use Mesh records.
return false;
}
bool
FltExportVisitor::atLeastOneMesh( const osg::Geometry geom ) const
{
// Return true if at least one PrimitiveSet mode will use a Mesh record.
unsigned int jdx;
for (jdx=0; jdx geom.getNumPrimitiveSets(); jdx++)
{
const osg::PrimitiveSet* prim = geom.getPrimitiveSet( jdx );
if( isMesh( prim-getMode() ) )
return true;
}
// All PrimitiveSet modes will use Face records.
return false;
}
void
FltExportVisitor::writeFace( const
[osg-users] Framerate-(stats) stutter / hiccups
Hi, when running my osg-app (or the osgviewer.exe) I noticed there are from time to time some framerate-stutters (that seem independent from the scene). I've tested on several pcs (osg-trunk, win7, single/dual/quad core, nvidia graphics) with the same effects. To reproduce, I display a model (cow.osg) in the osgviewer.exe and let it spin - then every few seconds there are the hiccups. If I enable the stats these stutters let 'explode' the draw and gpu bars/values. I tried the different threading-models w/o any change - so I'm wondering if anyone else has seen this stutters? or maybe know how to minimize these effects? Thanks much! Cheers, Rob -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35010#35010 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] website down?
I haven't been able to access the website all day (http://www.openscenegraph.org/projects/osg). After churning for a while, I get this message displayed in my browser: Traceback (most recent call last): File /usr/lib/python2.5/site-packages/trac/web/api.py, line 339, in send_error 'text/html') File /usr/lib/python2.5/site-packages/trac/web/chrome.py, line 684, in render_template data = self.populate_data(req, data) File /usr/lib/python2.5/site-packages/trac/web/chrome.py, line 592, in populate_data d['chrome'].update(req.chrome) File /usr/lib/python2.5/site-packages/trac/web/api.py, line 168, in __getattr__ value = self.callbacks[name](self) File /usr/lib/python2.5/site-packages/trac/web/chrome.py, line 460, in prepare_request for category, name, text in contributor.get_navigation_items(req): File /usr/lib/python2.5/site-packages/trac/versioncontrol/web_ui/browser.py, line 295, in get_navigation_items if 'BROWSER_VIEW' in req.perm: File /usr/lib/python2.5/site-packages/trac/perm.py, line 523, in has_permission return self._has_permission(action, resource) File /usr/lib/python2.5/site-packages/trac/perm.py, line 537, in _has_permission check_permission(action, perm.username, resource, perm) File /usr/lib/python2.5/site-packages/trac/perm.py, line 424, in check_permission perm) File /usr/lib/python2.5/site-packages/trac/perm.py, line 282, in check_permission get_user_permissions(username) File /usr/lib/python2.5/site-packages/trac/perm.py, line 357, in get_user_permissions for perm in self.store.get_user_permissions(username): File /usr/lib/python2.5/site-packages/trac/perm.py, line 175, in get_user_permissions cursor.execute(SELECT username,action FROM permission) File /usr/lib/python2.5/site-packages/trac/db/util.py, line 51, in execute return self.cursor.execute(sql) File /usr/lib/python2.5/site-packages/trac/db/sqlite_backend.py, line 58, in execute args or []) File /usr/lib/python2.5/site-packages/trac/db/sqlite_backend.py, line 50, in _rollback_on_error return function(self, *args, **kwargs) OperationalError: database is locked Anyone know what's wrong? Rob smime.p7s Description: S/MIME Cryptographic Signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Several questions regarding Terrain
Hi, I would like to be able to load the terrain format used by the Torque Game Engine. A couple questions about how to use the Terrain mechanisms built in to OpenSceneGraph: If I have a heightfield which tiles cleanly, is there a mechanism to make a terrain repeat indefinitely? Is there any sort of mechanism to draw a hole in a patch of terrain? If not, how would such a thing be implemented? Can you have multiple layers of texture over the same heightfield? (i.e. a background texture and another detail texture painted over it? In the documentation I see names like TerrainTechnique Layer Terrain and TerrainTile being thrown around without much description of the roll of any individual class. Is this documented in any reasonable form somewhere, or would someone care to explain them? Thank you! Cheers, Thomas Vermont Sustainable Heating Initiative (http://www.sustainableheatingvt.org) || Village2Village Project (http://www.village2villageproject.org) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35012#35012 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VertexBufferObject usage very slow...
Robert, Wojciech, Thank you for the advice, this is pretty much exactly what I discovered after some further research. This particular code is pretty old, and I've now re-factored it to use indexed tri-sets instead of tri-strips and things are much better. While digging, it looks like there are several ways to optimize vertex arrays for the caches on various GPUs...have you looked at all at this? Are there any reasonable rules-of-thumb for organizing the vertex arrays such that they make efficient use of the vertex cache across a wide swath of commodity hardware? Both NVIDIA and ATI have published advice on the topic. sean _ Sean Spicer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 On Sun, Dec 19, 2010 at 6:20 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Sean, In general when moving from display listed data to VBO's it's best to avoid using tri-strips with separate osg::DrawElements and instead using a single osg::DrawElements containing just GL_TRIANGLES. This will be more duplicated indices but far less overhead in set up and dispatch. With modern graphics hardware and API the biggest overhead is typically the dispatch rather than vertex load on the GPU. Even mid range GPU's can comfortable handle a million+ vertices per frame at 60hz, but... you have to pass the data to them efficiently, and the bottlenecks we were once familiar with have changed. Robert. On Fri, Dec 17, 2010 at 6:57 PM, Sean Spicer sean.spi...@aqumin.com wrote: Robert, Some more data... Looks like we're drawing approx 100K tri-strips every frame. The glDrawElements call is the culprit...though I'm still baffled by why it is so much slower with VBOs than in immediate mode. Perhaps the drawing isn't sorted by VBO so that all of the triangles drawn from each VBO are draw in single bind call ? sean _ Sean Spicer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 On Fri, Dec 17, 2010 at 11:37 AM, Sean Spicer sean.spi...@aqumin.com wrote: Hi Robert, We are not updating the data frame-to-frame, which is why this is so baffling. I'm working through the issue with gDebugger now - if you don't have any suggestions off the top of your head, then I'll start digging and report back what I find, since I don't have time try and duplicate the issue outside our app. cheers, sean _ Sean Spicer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 On Fri, Dec 17, 2010 at 2:36 AM, Robert Osfield robert.osfi...@gmail.com wrote: reproduces the problem you are seeing? ___ 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
