Re: [osg-users] About vpbmaster problem
Hi GuiYe, do you want a smooth elevation transition from area with DEM to area without DEM? Then you have several possibilities: a) modify your DEM sources to a image format, and at the border of your DEM region blend the gray values smoothly into the null value b) modify your viewer to perform runtime elevation modifikation to create a smooth transition c) Modify osgdem to create the transition. Thank you! Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39446#39446 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Ciao, So, looks like we have a decision, cool! To summarize, if I've got it right, for every texture map in the material we will find a description string like the following (assuming we use the | as a separator): Diffuse|Unit_0|c:\program files\whatever\file.png|80 where: - the first field is the texture map name followed by a | sign; - the second field is the map file name, followed by a | sign - the third field is the blend amount (in the [0-100] range) Any additional parameter that might be needed by the specific channel would just be an additional field (and it would be up to the parser to know its meaning of course). Is that right? Note that I would avoid the = and just use the | to separate all fields; this makes it easier to tokenize the string (I'm lazy...). About bump, as far as I know Max allows you to create for that channel a map of type normal and therefore you should be able to distinguish between regular bump mapping and normal mapping. Actually Max allows even to specify what space to use for the normal map (tangent, local, screen...) so maybe we could even add that extra param in the description string. Anything we can do here to help on this, apart from testing? Can't wait to give it a try... Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39447#39447 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] About vpbmaster problem
Thank you very much for your reply! Yes,I want to do a smooth elevation transition from area with DEM to area without DEM. About this possibility: a) modify your DEM sources to a image format, and at the border of your DEM region blend the gray values smoothly into the null value Can you give me more information?The dem.tif is some of ASTER 30m Data.How I should do ? Thank you ! Cheers, GuiYe At 2011-05-17 14:21:40，Torben Dannhauer tor...@dannhauer.info wrote: Hi GuiYe, do you want a smooth elevation transition from area with DEM to area without DEM? Then you have several possibilities: a) modify your DEM sources to a image format, and at the border of your DEM region blend the gray values smoothly into the null value b) modify your viewer to perform runtime elevation modifikation to create a smooth transition c) Modify osgdem to create the transition. Thank you! Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39446#39446 ___ 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] picking to select an object
HI Camile,
You simply need to walk back from of the end of the
Intersection::nodePath to the first group, of which ever one you wan
to use.
If you want to see an example of highlighitng picked items have a look
at the osgkeyboard mouse.
Cheers,
Robert.
On Mon, May 16, 2011 at 11:24 PM, camille matan techma...@gmail.com wrote:
Hi,
I want to select an object after a picking.
I found how to do picking but i don't know how to get the group that
corresponds to the picked zone.
My scene is composed of simple shapes (shapedrawable, geodes and group).
I want to get the first group in the hierarchy.
Code:
#ifndef _picking_h
#define _picking_h
#include osg/MatrixTransform
#include osg/ShapeDrawable
#include osg/PolygonMode
#include osgUtil/LineSegmentIntersector
#include includer.h
#include animation.h
#include rotate.h
#include dove.h
class PickHandler : public osgGA::GUIEventHandler
{
public:
osg::Node* getOrCreateSelectionBox()
{
if ( !_selectionBox )
{
osg::ref_ptrosg::Geode geode = new osg::Geode;
geode-addDrawable(new osg::ShapeDrawable(new
osg::Box(osg::Vec3(), 1.0f)) );
_selectionBox = new osg::MatrixTransform;
_selectionBox-setNodeMask( 0x1 );
_selectionBox-addChild( geode.get() );
osg::StateSet* ss = _selectionBox-getOrCreateStateSet();
ss-setMode( GL_LIGHTING, osg::StateAttribute::OFF );
ss-setAttributeAndModes( new
osg::PolygonMode(osg::PolygonMode::FRONT_AND_BACK, osg::PolygonMode::LINE) );
}
return _selectionBox.get();
}
virtual bool handle( const osgGA::GUIEventAdapter ea,
osgGA::GUIActionAdapter aa )
{
if ( ea.getEventType()!=osgGA::GUIEventAdapter::RELEASE ||
ea.getButton()!=osgGA::GUIEventAdapter::LEFT_MOUSE_BUTTON ||
!(ea.getModKeyMask()osgGA::GUIEventAdapter::MODKEY_CTRL) )
return false;
osgViewer::Viewer* viewer = dynamic_castosgViewer::Viewer*(aa);
if ( viewer )
{
osg::ref_ptrosgUtil::LineSegmentIntersector intersector = new
osgUtil::LineSegmentIntersector(osgUtil::Intersector::WINDOW, ea.getX(),
ea.getY());
osgUtil::IntersectionVisitor iv( intersector.get() );
iv.setTraversalMask( ~0x1 );
viewer-getCamera()-accept( iv );
if ( intersector-containsIntersections() )
{
const osgUtil::LineSegmentIntersector::Intersection result
=*(intersector-getIntersections().begin());
// const osgUtil::LineSegmentIntersector::Intersection
result =*(intersector-getIntersections().begin());
osg::BoundingBox bb = result.drawable-getBound();
osg::Vec3 worldCenter = bb.center() *
osg::computeLocalToWorld(result.nodePath);
_selectionBox-setMatrix(osg::Matrix::scale(bb.xMax()-bb.xMin(),
bb.yMax()-bb.yMin(), bb.zMax()-bb.zMin()) *
osg::Matrix::translate(worldCenter) );
}
}
return false;
}
protected:
osg::ref_ptrosg::MatrixTransform _selectionBox;
};
#endif
i think that I do something like that :
osg::Node = result.drawable-getParent();
or
osg::Nodepath = result.nodepath;
but i want finally a osg::Group.
Thank !
Camille[/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39433#39433
___
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] How to get position of sub-drawable object from PositionAttitudeTransform
anybody knows that? using osg::Node* findNamedNode(const std::string searchName, osg::Node* currNode)? Thank you! Cheers, Nan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39450#39450 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgexport for blender?
sorry but it doesn't work :( even with the simple default blender cube no file is exported !!! and for more complex objects i got a crash -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39451#39451 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText::Text character spacing
Hi Thirston, On Mon, May 16, 2011 at 10:55 PM, Thorsten Brehm bre...@gmail.com wrote: thanks for looking into the txf font issue. Your patch fixed the issue for me - thanks resolving this so quickly! Good to hear things working better again. I got one report though, saying the txf font is still slightly larger than it used to be - so some of our text labels don't fit any longer. I haven't been able to see/compare this myself though. I'll try that in a few days. Text sizing will be a little different as I there were bugs in the way that 2D and 3D text was sized, while now the two are consistent, and different resolutions of the glyphs don't affect the results. These bug fixes will lead to changes in sizes which is difficult to avoid - the new sizing should be more accurate to what size is actually requested, but this doesn't help you if the original coder has adjusted the sizing to account for the previous sizing. I guess the best way to handle it would be to adjust the sizing depending upon OSG version, or simply reduce the label sizing so that the new text labels are correct w.r.t OSG svn/trunk. The later approach would lead to labels that are too small but if the difference isn't significant you might be able to get away with this. I'll be releasing the next dev release this week and I really don't want OSG-3.0 to be too far out, so shoudl be out in time for the next rev of OpenFlight unless this is imminent. What is the schedule for the next OpenFlight release? And btw: we've been presenting FlightGear at LinuxTag/Berlin last week. We were busy all days, so people obviously really liked our little flight-sim setup - with 10 TFT displays driven by a single system with 5 graphics cards: http://img607.imageshack.us/img607/3381/08stand2.jpg We used another smaller setup to show stereoscopic (anaglyphic) view - both proved to be real eye catchers. A number of people specifically asked which graphics engine enabled this. So, thanks to you - and everyone else here contributing to osg! 10 displays, that's impressive number to be driven by a single machine. What is the framerate like? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] About vpbmaster problem
Hi, You use ASTER data? Am I right that ASTER is public available? I played 2 years ago with the ASTER data as it was initially released. It has great resolution, but it had also lots of artefacts. Do you use raw or somehow corrected ASTER data? - As you can see, I'm on the never ending quest for public available DEM and texture data :) Well, in the DEM raster data, some value represents zero meters elevation. To achieve a smooth transition, you should blend at the border of your source images from your original value to that null value. In a geotiff, this would be a blending of the grey value (which represents the elevation). You can perform this blending in a graphical software like gimp. Your blending zone has to be a frame at the border of your DEM region. You have to blend from the original elevation value to the 0 meters elevation value -for example with a alpha value ramp (inside your blending zone 100% elevation and 0% 0-meters-color, at the outer border of your DEM-Data 0% elevation and 100% 0-meters-color) Sorry for that bad explanation.. :) Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39454#39454 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
vezza wrote: About bump, as far as I know Max allows you to create for that channel a map of type normal and therefore you should be able to distinguish between regular bump mapping and normal mapping. Actually Max allows even to specify what space to use for the normal map (tangent, local, screen...) so maybe we could even add that extra param in the description string. I've made a few tests with the current (trunk) version of the exporter and I'd say it doesn't handle the normal maps for now. In Max, to use a normal map you don't assign directly a bitmap to the bump channel, you first create the map of type normal, then assign the bit map to it. So there is an extra texture node to go through. I guess the exporter could be extended to check if the bump texture is not a bitmap in which case it could try to interpret is as a normal map. No idea how to do it though as I don't know the max SDK ... :( Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39455#39455 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Integer vertex attribute issue. Repro included.
robertosfield wrote: I didn't even realize there was a glVertexAttribIPointer... so yes this does sound like it will be the issue. Either osg::Geometry::drawImplementation or osg::State will need to be adapted to detect the use of the interger array and use the glVertexAttribIPointer. Feel free to dive into the code and add this handling. Thanks. I actually didn't know this either. OK I'm going to look at the code, I think I should be able to make this change. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39456#39456 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Hi Robert,
I have a serious, massive memory leak in the trunk (updated this morning at
around 10am UK time). I haven't tried with previous releases yet.
The following code leaks memory in a very important manner. Put this code
within a while (true) { testLeak(); } block and you should see memory usage
climbing fast. I'm testing on a Windows XP 32-bit system. I tried multiple
Nvidia driver versions, just to be sure I had the same results.
Code:
void testLeak()
{
osg::ref_ptrosgViewer::Viewer viewer = new osgViewer::Viewer();
osg::ref_ptrosg::DisplaySettings ds = new osg::DisplaySettings();
osg::ref_ptrosg::GraphicsContext::Traits traits = new
osg::GraphicsContext::Traits(ds.get());
traits-width = 64;
traits-height = 64;
traits-pbuffer = true;
// This probably is the offending line
osg::ref_ptrosg::GraphicsContext gc =
osg::GraphicsContext::createGraphicsContext(traits.get());
}
This problem is making my life difficult at the moment as I do not have a
reliable way of doing a large amount of RTT.
This method for doing RTT using a separate pbuffer context is subject to a
memory leak. The other method using an ASBOLUTE_RF slave camera is also causing
some troubles. I am working on a repro to illustrate the latter. I would
appreciate any feedback on the above mentioned issue.
Cheers,
Fred
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39457#39457
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Hi Robert,
I am a bit puzzled as the second problem I am having at the moment yields a
very different behavior when isolated out in a small repro.
This time I get an assertion.
Attached is a modified osggeometry.cpp file that triggers the assertion I'm
talking about. The assertion is raised when addSlave() is called.
This issue might be by design, though. Not sure.
Code:
osg::Camera *createRTTCamera(osgViewer::Viewer viewer)
{
osg::ref_ptrosg::Camera slaveCamera = new osg::Camera();
slaveCamera-setClearColor(osg::Vec4(0, 0, 0, 1)); // initialize alpha
to 1
slaveCamera-setClearMask(GL_COLOR_BUFFER_BIT);
osg::Matrixd projMatrix;
projMatrix.makeOrtho(0.0, (double)1, 0.0, (double)1, -1.0, 1.0);
slaveCamera-setProjectionMatrix(projMatrix);
slaveCamera-setReferenceFrame(osg::Transform::ABSOLUTE_RF);
osg::ref_ptrosg::Viewport viewport = new osg::Viewport(0, 0, 64, 64);
slaveCamera-setViewport(viewport.get());
osg::Matrixd viewMatrix;
slaveCamera-setViewMatrix(viewMatrix);
slaveCamera-setRenderOrder(osg::Camera::PRE_RENDER);
slaveCamera-setAllowEventFocus(false);
slaveCamera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
slaveCamera-setCullingMode(osg::CullSettings::NO_CULLING);
osg::ref_ptrosg::Camera masterCamera = viewer.getCamera();
slaveCamera-setGraphicsContext(masterCamera-getGraphicsContext());
return slaveCamera;
}
void testRTTCamera(osgViewer::Viewer viewer)
{
int oldNodeMask = viewer.getCamera()-getNodeMask();
viewer.getCamera()-setNodeMask(0);
osg::ref_ptrosg::Camera camera = createRTTCamera(viewer);
viewer.addSlave(camera.get(), false);
viewer.frame();
viewer.removeSlave(0);
viewer.getCamera()-setNodeMask(oldNodeMask);
}
void main(void)
{
osgViewer::Viewer viewer;
viewer.setUpViewInWindow(10, 10, 640, 480);
viewer.setThreadingModel(osgViewer::ViewerBase::SingleThreaded);
// add model to viewer.
viewer.setSceneData( root );
viewer.realize();
// Call this method to test the problem mentioned in the current message,
i.e. the slave camera issue. An assertion is raised when addSlave() is called.
Why?
testRTTCamera(viewer);
// Use this code to test the problem mentioned in my previous thread, eg.
the pbuffer leak issue. Memory usage will skyrocket
//while (true)
// testLeak();
viewer.run();
}
Cheers,
Fred
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39460#39460
/* OpenSceneGraph example, osggeometry.
*
* 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/Geometry
#include osg/GraphicsContext
#include osg/Material
#include osg/Vec3
#include osg/MatrixTransform
#include osg/Texture2D
#include osg/PolygonStipple
#include osg/TriangleFunctor
#include osg/io_utils
#include osgDB/ReadFile
#include osgDB/WriteFile
#include osgGA/TrackballManipulator
#include osgViewer/Viewer
#include osg/Math
#include iostream
// This demo illustrates how to create the various different types of geometry that
// the osg::Geometry class can represent. This demo uses the OpenGL red book diagram of different
// OpenGL Primitives as a template for all the equivalent OpenSceneGraph Primitives. The OpenSceneGraph
// wraps OpenGL very thinly and therefore uses all the same enum and naming conventions. The coordinate data is also
// wrapped around OpenGL's vertex arrays and draw arrays/elements calls. Familiarity with
// OpenGL will help you understand the osg::Geometry class which encapsulate all this, or if you
// havn't learned OpenGL yet, learning osg::Geometry will help you understand how OpenGL
// works!
// The osg::Geometry class is a subclass of osg::Drawable base class, so is an object that provides
// a draw method for drawing objects in
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Guys Been following this with interest. Having a method to know what map type is in what texture unit will be great. Regarding the normal mapping, is there any chance of getting the exporter to also generate tangent vectors (either from max or using osgUtils). Would be ace if you could also specify the channel to bind and the name to use in the shader e.g. channels 6 and 7 with names osg_tangent, osg_binormal Or do people feel tangents should always be generated at runtime? Cheers Tom ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Farshid Lashkari wrote: The description would be added to the osg::StateSet object. Our use of the word material is referring to the Max material object. Mmm... StateSet does not derive from osg::Node so it does not have the DescriptionList member... So are you planning to extend the StateSet class, its serializer and so on? Or did I miss something?... Thanks, Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39463#39463 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and nested RTT-cams
On 5/16/2011 12:55 PM, Paul Martz wrote: So I always recommended using Slaves cameras instead of Nested cams because they have their own CullVisitors. If I would design this today, instead of CullVisitor I would probably use RenderStage to index view resources. Understood. This is ViewerBase::RenderingTraversals, where it calls renderer-cull(). That's implemented internally with SceneView::cull(). Wojtek, in your experience, have you found that using multiple slave Cameras in this way causes StandardShadowMap (for example) to do a shadow map creation pass once for each slave Camera? There are multiple shadow map creation render passes done per frame, in other words. It seems like slave Cameras are really designed more for multiple displays, in which case you *do* want a shadow map created for each slave camera (so that it's generated and resident on the per-display GPU). But if the application uses slave Cameras rendering to a single window, the shadow map would still get generated multiple times per frame -- once per slave Camera -- which is undesirable. It seems like what we really want for shadow map creation is something that creates the shadow map once per frame#/GC pair. As far as I can tell, merely using slave Cameras doesn't achieve this. If I'm wrong about how StandardShadowMap works in the presence of multiple slave Cameras, please correct me. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Same issues with OSG 2.9.10. Any idea about what's going on? Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39466#39466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgexport for blender?
Yep - it's not real stable right now. But I got the unit tests up and running on my copy now - (1 out of 5 passes) so I'll work on fixing them and post a new version. I also noticed when it's run from blender it saves the file to Scene.osg in the current directory regardless of the file you tell it. You may have seen that and thought you got no output with the default cube. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39467#39467 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Am 17.05.11 14:44, schrieb Fred Smith:
Hi Robert,
I am a bit puzzled as the second problem I am having at the moment yields a
very different behavior when isolated out in a small repro.
This time I get an assertion.
Attached is a modified osggeometry.cpp file that triggers the assertion I'm
talking about. The assertion is raised when addSlave() is called.
This issue might be by design, though. Not sure.
Code:
osg::Camera *createRTTCamera(osgViewer::Viewer viewer)
{
osg::ref_ptrosg::Camera slaveCamera = new osg::Camera();
slaveCamera-setClearColor(osg::Vec4(0, 0, 0, 1)); // initialize alpha
to 1
slaveCamera-setClearMask(GL_COLOR_BUFFER_BIT);
osg::Matrixd projMatrix;
projMatrix.makeOrtho(0.0, (double)1, 0.0, (double)1, -1.0, 1.0);
slaveCamera-setProjectionMatrix(projMatrix);
slaveCamera-setReferenceFrame(osg::Transform::ABSOLUTE_RF);
osg::ref_ptrosg::Viewport viewport = new osg::Viewport(0, 0, 64, 64);
slaveCamera-setViewport(viewport.get());
osg::Matrixd viewMatrix;
slaveCamera-setViewMatrix(viewMatrix);
slaveCamera-setRenderOrder(osg::Camera::PRE_RENDER);
slaveCamera-setAllowEventFocus(false);
slaveCamera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
slaveCamera-setCullingMode(osg::CullSettings::NO_CULLING);
osg::ref_ptrosg::Camera masterCamera = viewer.getCamera();
slaveCamera-setGraphicsContext(masterCamera-getGraphicsContext());
return slaveCamera;
This will certainly lead to a crash, as slaveCamera gets deconstructed,
as the correpsonding ref_ptr goes out of scope. Try
return slaveCamera.release()
or change the signature of the function to
osg::ref_ptrosg::Camera createRTTCamera(osgViewer::Viewer viewer)
instead.
Can't comment much on the memory-leak issue, though.
cheers,
Stephan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Hi, Thanks Stephan, you actually replied to my original message. I have since edited it and suggested to concentrate on the leak issue. The other issue I have is still under investigation and yes, the code I had originally posted (too fast) to illustrate the second issue was incorrect ;) Thank you! Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39469#39469 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] About vpbmaster problem
Thank you! How about strm 90m DEM? Do you make terrain in earth as I do? Cheers, GuiYe At 2011-05-17 17:35:48，Torben Dannhauer tor...@dannhauer.info wrote: Hi, You use ASTER data? Am I right that ASTER is public available? I played 2 years ago with the ASTER data as it was initially released. It has great resolution, but it had also lots of artefacts. Do you use raw or somehow corrected ASTER data? - As you can see, I'm on the never ending quest for public available DEM and texture data :) Well, in the DEM raster data, some value represents zero meters elevation. To achieve a smooth transition, you should blend at the border of your source images from your original value to that null value. In a geotiff, this would be a blending of the grey value (which represents the elevation). You can perform this blending in a graphical software like gimp. Your blending zone has to be a frame at the border of your DEM region. You have to blend from the original elevation value to the 0 meters elevation value -for example with a alpha value ramp (inside your blending zone 100% elevation and 0% 0-meters-color, at the outer border of your DEM-Data 0% elevation and 100% 0-meters-color) Sorry for that bad explanation.. :) Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39454#39454 ___ 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] [osgPlugins] 3ds repeating textures problem
Hello Sami,
This should be corrected by this just posted submission:
*file lib3ds_material.c*
*
*
static void
initialize_texture_map(Lib3dsTextureMap *map) {
*map-flags = 0x00;*
map-percent = 1.0f;
map-scale[0] = 1.0f;
map-scale[1] = 1.0f;
}
Regards
Joan Abadie
2011/5/16 Sami Moisio smoi...@lut.fi
Hi,
I have been investigating the problem a bit and i thought i'd clarify it a
little bit just in case someone with a little more knowledge might get
interested :)
I have been using Blender to create 3ds files and then importing them to
osg using the importer. I have been creating the repeating textures to the
models by scaling the UV coordinates past 1 and that has been working
before. I have been trying to get the repeat from blender to work in the osg
but it's not working. So previously the way it worked was to scale the UV
coordinates. Now however the UV coordinates aren't repeating over 1. So does
anyone know if there has been a change in the 3ds importer regarding the
texture repeat? Changing from repeat to clamp? Tried to do a search but i
didn't find anything on it yet.
In any case there seems to be a problem with UV mapping.
Thank you!
Cheers,
Sami
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39404#39404
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
jOan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Hi, The second issue I had was that by design OSG doesn't assume the bounding box of a drawable should be recalculated when setting a computeBoundingBoxCallback up on the object. In other words I was expecting Drawable::_boundingBoxComputed to be set back to false when setting the callback. Shouldn't this be done? Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39472#39472 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Performace issue with nVidia 400 series
Hi, we have a performance problem with the nVidia 400 series. But first: Our software is a 3D physics simulation. We use ODE for the physics. Qt is responsible for the 2D GUI and OSG handles the 3D visualisation. I changed my graphics-card from a nVidia 9600GT to a nVidia GTX460 (768mb of RAM). After this the performance goes down. It is roughly half of the FPS. I found this statement in the wikipedia: OpenGL Problems It has been reported by users as well as developers [13] [14] [15] [16] [17] [18] [19] [20] that nVidia 400-series cards have severe performance problems with 3D content-creation applications such as Autodesk Maya and 3ds Max, Blender, Rhinoceros 3D—as well as some OpenGL games—to the extent that video cards two generations older routinely outperform 400-series in such applications and games. The problem, which affects any OpenGL application using textures, involves accessing framebuffer contents or storing data on the GPU. So far, one customer using an OpenGL based application got a response from nVidia support indicating that the behavior is expected in the GeForce 400 line of cards, and no software update is available to improve the performance of the hardware.[21]. The problem can be worked around with a hack by using a CUDA memory copy to access the buffer object. Here is the link: http://en.wikipedia.org/wiki/GeForce_400_Series#OpenGL_Problems Is there a known issue? I searched the board but I had no success. The problem is also present on a nVidia GTX480. Some details from our software: OSG: 2.8.3 / 2.8.4 and 2.9.14 (I tested all these versions) Qt: 4.6.3 (SDK 2010.04) ODE: 0.11 build with minGW (from the Qt SDK) running under Win7 64bit nVidia driver: 270.61 Did I miss anything? ... Thank you! Cheers, Michael[/url] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39474#39474 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Luca, On Tue, May 17, 2011 at 4:29 AM, Luca Vezzadini luca.vezzad...@gmail.comwrote: I've made a few tests with the current (trunk) version of the exporter and I'd say it doesn't handle the normal maps for now. In Max, to use a normal map you don't assign directly a bitmap to the bump channel, you first create the map of type normal, then assign the bit map to it. So there is an extra texture node to go through. I guess the exporter could be extended to check if the bump texture is not a bitmap in which case it could try to interpret is as a normal map. No idea how to do it though as I don't know the max SDK ... :( It should export if you enable unknown maps in the export options. However, this seems to force the normal map to 256x256. I'll see about adding direct support for normal maps. Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Luca, On Tue, May 17, 2011 at 6:12 AM, Luca Vezzadini luca.vezzad...@gmail.comwrote: Mmm... StateSet does not derive from osg::Node so it does not have the DescriptionList member... So are you planning to extend the StateSet class, its serializer and so on? Or did I miss something?... You are absolutely right! I had mistakenly assumed that the description list was supported by all osg::Object derived classes. Well, that puts a big dent in our plans :( Does anybody know if the new meta-data system will support all osg::Object derived classes? One option would be to put the description string in the name of the stateset object. Another option would be to use the user data field, but that would require a custom serializer. Let me know if you have another idea. Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Farshid, Luca, You are absolutely right! I had mistakenly assumed that the description list was supported by all osg::Object derived classes. Well, that puts a big dent in our plans :( Argh, I had made the same assumption. Does anybody know if the new meta-data system will support all osg::Object derived classes? I think so, since it will essentially supersede the UserData. I think that's why we made the wrong assumption above. One option would be to put the description string in the name of the stateset object. Another option would be to use the user data field, but that would require a custom serializer. In the name, that would make a really long name! In the UserData might be a good idea if we can think of a way to make it readable for anyone. I guess it would also limit us to using the new formats (osgt, osgb, osgx) and not the old ones (osg, ive). Let me know if you have another idea. Nope, not for now... I'll keep thinking about it though. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and nested RTT-cams
Hi, On 5/16/2011 12:55 PM, Paul Martz wrote: So I always recommended using Slaves cameras instead of Nested cams because they have their own CullVisitors. If I would design this today, instead of CullVisitor I would probably use RenderStage to index view resources. Understood. This is ViewerBase::RenderingTraversals, where it calls renderer-cull(). That's implemented internally with SceneView::cull(). Wojtek, in your experience, have you found that using multiple slave Cameras in this way causes StandardShadowMap (for example) to do a shadow map creation pass once for each slave Camera? There are multiple shadow map creation render passes done per frame, in other words. Yes. It does. However StandardShadowMap is not intended for wide use in practice. This class is a direct equivalent of ShadowMap. It is fully functional, so can be used as a replacement of ShadowMap, but its main role is to lay foundation for View Dependent Shadow Techniques derived from it. It seems like slave Cameras are really designed more for multiple displays, in which case you *do* want a shadow map created for each slave camera (so that it's generated and resident on the per-display GPU). But if the application uses slave Cameras rendering to a single window, the shadow map would still get generated multiple times per frame -- once per slave Camera -- which is undesirable. And thats the goal for View Dependent techniques which optimize shadow map resolution by adjusting shadow projection to part of the scene visible per view. So each view will need a different shadow map. These classes were designed to work in multi screen / multi threaded configurations. But they would also work for RTT Slave cameras. It seems like what we really want for shadow map creation is something that creates the shadow map once per frame#/GC pair. As far as I can tell, merely using slave Cameras doesn't achieve this. If I'm wrong about how StandardShadowMap works in the presence of multiple slave Cameras, please correct me. In case of MinimalShadowMap or LispSM techniques even if views share GC there is an assumption they use different view/projection matrices so Shadow maps for each of them should be created anyway. Cheers, Wojtek ___ 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] Performace issue with nVidia 400 series
On 05/17/2011 11:36 AM, Michael Rohn wrote: Is there a known issue? I searched the board but I had no success. The problem is also present on a nVidia GTX480. Look at the links on the Wikipedia page (especially the link to the OpenGL forum discussion). I haven't seen any official statement on the issue from nVidia, but the conjecture on the forums seems to be that it's a deliberate throttling of performance to create a product line separation between the GeForce gamer cards and the Quadro professional cards (Quadro cards are priced many times higher than the comparable GeForce product). Traditionally, games haven't needed quick pixel readback as much as other applications (GPU-heaving computational or scientific applications), so nVidia seems to be making it a professional feature and charging a premium for it. As the article mentions, you can get around it using CUDA code (and possibly OpenCL code as well), although that's obviously not a real solution. There seems to have been a bit of an uproar about this, so it remains to be seen if nVidia will address this issue or not. I suspect if enough people jump ship and start buying AMD cards, they might give it more attention. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] vrml plugin for 2.9.14
Hi all,
I was playing around with the dev release 2.9.14 on Windows (not the
latest svn) and had to play around with some build files to get it to
compile. I'm no guru on cmake by any stretch, but to compile the plugin I
had to edit one of the cmake files. First though, I downloaded openvrml
0.17.12 and used my existing boost build (1.44.0 the plugin readme says
to use an older version of boost, but I think this version works too). I
noticed that cmake wanted to find openvrml _antlr and _regex libraries,
but both are no longer used in openvrml. I commented out the following
lines in src/osgPlugins/vrml/CMakeLists.txt:
#FIND_LIBRARY(OPENVRML_ANTLR_LIBRARY
#NAMES antlr.lib
#PATHS $ENV{OPENVRML_DIR}/lib)
#FIND_LIBRARY(OPENVRML_ANTLR_LIBRARY_DEBUG
#NAMES antlrd.lib
#PATHS $ENV{OPENVRML_DIR}/lib)
#FIND_LIBRARY(OPENVRML_REGEX_LIBRARY
#NAMES regex.lib
#PATHS $ENV{OPENVRML_DIR}/lib)
#FIND_LIBRARY(OPENVRML_REGEX_LIBRARY_DEBUG
#NAMES regexd.lib
#PATHS $ENV{OPENVRML_DIR}/lib)
and
SET(TARGET_LIBRARIES_VARS
#OPENVRML_ANTLR_LIBRARY
#OPENVRML_REGEX_LIBRARY
OPENVRML_LIBRARY
JPEG_LIBRARY
PNG_LIBRARY
ZLIB_LIBRARY)
Then I was able to run cmake without a problem.
The last thing I had to do was to set one of the use/build macros
defined in the openvrml library file openvrml-config.h. You need
to choose either OPENVRML_USE_DLL or OPENVRML_USE_LIB depending on
whether you are linking to dynamic or static libs. In VisualStudio, you
just open up the properties window, find the Preprocessor menu under
Configuration Properties-C/C++. Then click Preprocessor Definitions
and add eitherOPENVRML_USE_DLL or OPENVRML_USE_LIB.
I didn't notice any mention of this in the osg-users list, so I thought
I'd send this out in case anyone else had this problem. If there is a
cleaner solution that I missed, please do correct me.
Thanks,
-K
Keith ParkinsU of R Center for Visual Science
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi, I have no idea about the new metadata stuff. But if that doesn't work, wouldn't it be easier to just move the description stuff from Node to Object? The name is already in the Object class, having the description there too would make a lot of sense anyway. And I don't this this would be a major refactor, right? Of course we need Robert's buy-in for this. For sure I would avoid using the name to encode all that info, that would really be ugly. I'd rather go back to the idea of predefined mapping among map channels and texture units... Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39482#39482 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transformation nodes with shaders
Hi Robert, Thanks for the tips and I set the UseModelViewAndProjectionUniforms flag on the Viewer-Camera-GraphicsContext-State object. However when I do this then absolutely nothing shows up on screen. Basically what I've had to do is manually append the view matrix onto each light's model transformation each frame and that gives the expected transformation. I'm not really sure why the OSG way isn't working but will have to debug it later. Chris On Mon, May 16, 2011 at 9:50 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Chris, On Sun, May 15, 2011 at 9:45 AM, SkullCheck csklu...@gmail.com wrote: I've dug into the OSG source code a bit and found the following: - special osg_* uniforms are maintained in the State class, the ones of interest are osg_ModelViewProjectionMatrix, osg_Vertex, etc This are drop in replacements for the traditional gl_ variables that are provided in OpenGL 2.x's GLSL. These replaements are required for GL3+ (with backwards compatibility) and GLES 2 as neither provide the gl_ varaibles. For a GL 2.x app it's safe to just target the gl_ variables. - the updating of these uniforms during draw traversal must be enabled by calling State::setUseModelViewAndProjectionUniforms(true) I'm not quite sure where to set this though since States are used in multiple places, I've tried the following: osgViewer::Viewer * viewer = new osgViewer::Viewer; osgViewer::Renderer * renderer = dynamic_castosgViewer::Renderer *(viewer-getCamera()-getRenderer()); osgUtil::SceneView * sceneView = renderer-getSceneView(0); // Do this also for 2nd sceneview sceneView-setActiveUniforms( osgUtil::SceneView::ALL_UNIFORMS ); sceneView-getState()-setUseModelViewAndProjectionUniforms(true); The osg::State object is held by the GraphicsContext, you don't need to go chasing up internal implementation details like SceneView. If you have just one master camera that maintains the only one graphics context the code is simply: osg::State* state = viewer.getCamera()-getGraphicsContext()-getState(); For the GL3 and GLES2 profiles the OSG automaitcally setUseModelViewAndProjectionUniforms(true); - Modify the shader source to use the special osg_* built-in uniforms: osg::ref_ptrosg::State state = new osg::State; state-convertVertexShaderSourceToOsgBuiltIns( srcString ); shader-setShaderSource(srcString); (Couldn't osg::State::convertVertexShaderSourceToOsgBuiltIns() be a static method or free function?) This method is called when required, you never need to call it yourself. This method is purely there to help with backwards compatibility between GL 2.x and GL3/GLES2 apps. But when I do this, then nothing appears. What am I doing wrong or are there other things I should be doing? It does sound rather like you might be putting too much effort in, you may well be able to just use the standard gl_ built-ins. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Luca, Jean-Sébastien On Tue, May 17, 2011 at 12:46 PM, Luca Vezzadini luca.vezzad...@gmail.comwrote: I have no idea about the new metadata stuff. But if that doesn't work, wouldn't it be easier to just move the description stuff from Node to Object? The name is already in the Object class, having the description there too would make a lot of sense anyway. And I don't this this would be a major refactor, right? Of course we need Robert's buy-in for this. If the new meta-data system is going to support all osg::Object derived classes, then all we need to do is just wait until it is complete. I think the bigger issue is being able to support older versions of osg and older formats like .osg/.ive. How about adding all the material descriptions to the root node of the model? Each material would have a separate entry in the description list of the node. This would require no changes to osg and would support the older model formats. We would just need to add the material name to the description string. Example: # osgmaxexp material info Material Name # Maps Diffuse 0 images/diffuse.jpg 100 Bump 1 images/bump.jpg 80 Does this seem like an acceptable solution? Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Farshid, If the new meta-data system is going to support all osg::Object derived classes, then all we need to do is just wait until it is complete. I think the bigger issue is being able to support older versions of osg and older formats like .osg/.ive. Yes. How about adding all the material descriptions to the root node of the model? Each material would have a separate entry in the description list of the node. This would require no changes to osg and would support the older model formats. I would prefer to add it to the description string of the node(s) on which a material is applied, since a model might have multiple materials on different nodes... i.e. your way would work if the model was made using a texture atlas so the same texture applies to the whole model, but if that isn't the case and multiple textures need to be applied to different parts of the model then we can't just put the material at the root node... We would just need to add the material name to the description string. Example: # osgmaxexp material info Material Name # Maps Diffuse 0 images/diffuse.jpg 100 Bump 1 images/bump.jpg 80 Does this seem like an acceptable solution? The format seems fine to me. Your separator is space, which seems more readable to me than the vertical bar we were discussing before, but it means parsers will have to handle the case where the filename is quoted and has spaces in it. Plus do any map names have spaces in them? In your list in a previous post, there was Specular Level that has a space... If you output it as Specular_Level for example, that's perfect I think. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Jean-Sébastien, On Tue, May 17, 2011 at 4:16 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: I would prefer to add it to the description string of the node(s) on which a material is applied, since a model might have multiple materials on different nodes... i.e. your way would work if the model was made using a texture atlas so the same texture applies to the whole model, but if that isn't the case and multiple textures need to be applied to different parts of the model then we can't just put the material at the root node... The exporter applies the material statesets to the osg::Drawable object, which does not support description strings. I can add the description to the parent osg::Geode. However, keep in mind that the geode can contain multiple drawables, where each drawable has a unique material applied. So you could still have multiple descriptions applied to the geode. So would you prefer adding the descriptions to the geode or root node? The format seems fine to me. Your separator is space, which seems more readable to me than the vertical bar we were discussing before, but it means parsers will have to handle the case where the filename is quoted and has spaces in it. Plus do any map names have spaces in them? In your list in a previous post, there was Specular Level that has a space... If you output it as Specular_Level for example, that's perfect I think. Actually, I've decided on using the tab character. This should avoid conflicts with filenames and seems more readable to me. Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Farshid, The exporter applies the material statesets to the osg::Drawable object, which does not support description strings. I can add the description to the parent osg::Geode. However, keep in mind that the geode can contain multiple drawables, where each drawable has a unique material applied. So you could still have multiple descriptions applied to the geode. So would you prefer adding the descriptions to the geode or root node? I think Geode is closer to the real intent than the root... Does the exporter give unique names to the Drawables? If so, then the description strings added to the Geode could say that Drawable named A has this material, Drawable named B has this material, and so on. This same scheme could be used at the root of the model, sure, but that would be much messier as lots of information would be at the same place. In the Geodes, at least it's just a small set of information (for the Geode's Drawables) that needs to be there. I agree it's not ideal... But until the metadata system on osg::Object lands (and for formats that won't support metadata), it's better than putting it on the root of the model IMHO. Actually, I've decided on using the tab character. This should avoid conflicts with filenames and seems more readable to me. Hmm, are you adamant on that? I personally don't like tabs, to the point that I configure all my editors to insert spaces instead of tabs when I press the Tab key... Plus, it can happen that the length of a token is 1 less than the tab length, and then your tab looks like a space visually, so you have to check it's really a tab... Tabs are unambiguous for the machine but seem ambiguous for humans to me. If you really want tab it's ok, as the strings will most of the time not be edited by hand, but space is just as readable and less ambiguous (visually) I think, apart for the filename issue. I tend to prefer things that are unambiguous to humans, even if it means more trouble to parse. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDB ifstream / ofstream conflict
Hi Vincent, I have been using Visual Studio 2010 and fstreams and OSG DLLs with no issues at all. The only possibility is you are compiling with incompatible compiler options between OSG and your other library. All files must be compiled /MD(d) and of course compiled with Visual Studio 2010. Make sure to include fstream not fstream.h etc You have not found a bug in Visual Studio 2010, I can guarantee that. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39488#39488 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Problem about DEM generation
Dear all, I use VPB to generate a dem with texture. It shows following error. Anybody can help me? / C:\OSGCode282\3rdParty_x86\bingdal_translate Beijing-XBL.tif texture16k.tif Input file size is 4104, 4200 0...10...20...30...40...50...60...70...80...90...100 - done. C:\OSGCode282\3rdParty_x86\bingdaladdo -r average texture16k.tif 2 4 8 16 32 0...10...20...30...40...50...60...70...80...90...100 - done. C:\OSGCode282\3rdParty_x86\bingdal_translate DEMsub3005Geo.tif DEM16k.tif Input file size is 4109, 4318 0...10...20...30...40...50...60...70...80...90...100 - done. C:\OSGCode282\3rdParty_x86\bingdaladdo -r average DEM16k.tif 2 4 8 16 32 0...10...20...30...40...50...60...70...80...90...100 - done. C:\OSGCode282\3rdParty_x86\binosgdem --xx 10 --yy 10 -t texture16k.tif --xx 10 --yy 10 -d DEM16k.tif -l 8 -v 0.1 -o puget.ive -a pegout.osga Warning: archive option -a is temporarily disabled, building with archive. --xx 10 --yy 10 -t texture16k.tif loaded layer texture16k.tif --xx 10 --yy 10 -d DEM16k.tif loaded layer DEM16k.tif -o puget.ive Adding terrainTile DataSet::_run() 0 0 DataSet::assignDestinationCoordinateSystem() : assigning first source file as th e destination coordinate system started DataSet::createDestination(8) Time for after_reproject 0.04 DataSet::assignDestinationCoordinateSystem() : assigning first source file as th e destination coordinate system AR=1.050864 C1=1 R1=1 createNewDestinationGraph Time for _destinationGraph-computeMaximumSourceResolution() = 0.009105 Time for createDestinationGraph 0.060909 Time for after_computeNeighbours 0.005470 completed DataSet::createDestination(8) There are 2 contributing source files: DEM16k.tif texture16k.tif PixelBufferWin32::init(), Error: some wgl extensions not supported Windows Error #127: [Screen #0] ChooseMatchingPixelFormat() - wglChoosePixelForm atARB extension not found, trying GDI. Reason: can not find the program。 Rendering in software: pixelFormatIndex 1 Windows Error #2000: Win32WindowingSystem::OpenGLContext() - Unable to restore c urrent OpenGL rendering context. Reason: invalid pixel format。 mkpath() Need to create output task directory = puget_root_L0_X0_Y0 Directory already created Task output directory = puget_root_L0_X0_Y0\ started DataSet::writeDestination(puget.ive) _readRow 1 reading tile level=0 X=0 Y=0 imageName = puget_L0_X0_Y0.dds DestinationTile::readFrom(SetName=, FileName=texture16k.tif) DestinationTile::readFrom(SetName=, FileName=DEM16k.tif) _equalizeRow 1 equalizing tile level=0 X=0 Y=0 _writeRow 1 DestinationTile::createStateSet() - DataSet::MIP_MAPPING_IMAGERY Compressed image Warning: detected OpenGL error 'Invalid enumeration' at DestinationTile::createStateSet() getDirectory()= writeNodeFile = 0 X=0 Y=0 filename=puget.ive _writeNodeFile(puget.ive) vpb::access(puget.ive, W_OK)=0 _readRow 1 reading tile level=1 X=0 Y=0 imageName = puget_L1_X0_Y0.dds DestinationTile::readFrom(SetName=, FileName=texture16k.tif) DestinationTile::readFrom(SetName=, FileName=DEM16k.tif) _equalizeRow 1 equalizing tile level=1 X=0 Y=0 _writeRow 1 _taskOutputDirectory= puget_root_L0_X0_Y0\ DestinationTile::createStateSet() - DataSet::MIP_MAPPING_IMAGERY Compressed image Caught exception. /// Thanks ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
