Re: [osg-users] Compress image
Hi Ufuk,
Ufuk wrote:
actually i just want to have a scale code of image..
half and quarter resolution would be enough for me..
i wanted to scale them when i create terrain.
if you are working with terrain I would suggest you also look at the
GDAL functions/lib. E.g. have a look at the gdaladdo man page, it is a
command line app that builds overview images, but you could use the same
functionality directly from your application if you link to GDAL. You
might also find some other helpful functions.
jp
i have a terrain editor and viewer which are 2 separate programs.
on editor, in saving process, i want to store lower resolution textures
too and i wanted to create in my program.
my terrain viewer program will load all textures and use low resolution
textures for pages which are far away from the camera..
i don't want to use .dds because in terrain editor, user can use any
texture he wants. so i don't want to give up texture selection dynamism
here.. i can't limit users just with my textures which are selected before.
On Thu, Aug 20, 2009 at 5:58 PM, Ümit Uzun umituzu...@gmail.com
mailto:umituzu...@gmail.com wrote:
Hi Ufuk;
If you want to create mippaped images on your disk instead of
programmaticaly. I suggest you to use GIMP to mipmap(rescale each
different resolution image separately) and when you need you can
call related resolution image :)
Is this your expected or you want to create one image which has all
resoluted images in it? If you want kind of this operation you can
use dds format. But I don't know osg does support reading mipmapped
dds format.
Regards.
Ümit Uzun
2009/8/20 Ufuk ufuk@gmail.com mailto:ufuk@gmail.com
Hi Ümit,
yes, i need mipmapping but i want to store these mipmapped
textures on disk. i dont want so many calculations on rendering...
so i wanted to store these images on disk.
do you know a way to do this or i should write a code?
On Thu, Aug 20, 2009 at 5:43 PM, Ümit Uzun umituzu...@gmail.com
mailto:umituzu...@gmail.com wrote:
Hi Ufuk;
Compress word doesn't define your expected operation very
well. This operation's name is Mipmapping. You should
generate automatic mipmapping for your texture in runtime
and the you can choose any resolution you have created to
use your program.
Regards.
Ümit Uzun
2009/8/20 Ufuk ufuk@gmail.com mailto:ufuk@gmail.com
is there any function that compress image in osg?
for example i have an 256x256 image and i want to
compress it to 128x128 or 64x64...
i checked for osg::Image::scaleImage() but it did not
change the resolution.. maybe i did something wrong?
Here is the code:
///
void simUtil::SimImageUtils::scaleAndSaveImage(
osg::Image* image, float scaleFactor, const std::string
filename )
{
osg::ref_ptrosg::Image cImage = new osg::Image(*image);
cImage-scaleImage(image-s() * scaleFactor,
image-t() * scaleFactor, image-r() * scaleFactor);
osgDB::writeImageFile(*image, filename);
}
///
--
Ufuk
___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Ufuk
___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Ufuk
Re: [osg-users] Need help regarding rendering to a texture
Hi Brett,
problem seems to be that lighting was on in your RTT camera. See
attached. I added
geode-getOrCreateStateSet()-setMode( GL_LIGHTING,
osg::StateAttribute::OFF);
Also be aware of the way OSG blends your RTT texture with your final
geometry. OSG defaults to GL_MODULATE. Search
http://news.gmane.org/gmane.comp.graphics.openscenegraph.user
for
GL_MODULATE or GL_DECAL and you'll find some things. Also look at
http://www.opengl.org/resources/faq/technical/texture.htm
rgds
jp
Brett Thomas Lee wrote:
Hi,
I have attached my expected and current output.Just remove the quotes for
osg::ref_ptrosg::Vec4Array c = new osg::Vec4Array;
geom-setColorBinding( osg::Geometry::BIND_PER_VERTEX );
c-push_back( osg::Vec4( 1.f, 0.f, 0.f, 1.f ) );
c-push_back( osg::Vec4( 0.f, 1.f, 0.f, 1.f ) );
c-push_back( osg::Vec4( 0.f, 0.f, 1.f, 1.f ) );
c-push_back( osg::Vec4( 1.f, 1.f, 1.f, 1.f ) );
and check once.Thanks again.
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.
#includeiostream
#includeosg/Camera
#includeosg/Geode
#includeosg/Geometry
#includeosg/Image
#includeosg/MatrixTransform
#includeosg/Material
#include osgDB/ReadFile
#include osg/ShapeDrawable
#includeosg/StateSet
#includeosg/StateAttribute
#includeosg/ShadeModel
#includeosg/Texture2D
#include osgGA/TrackballManipulator
#include osgViewer/Viewer
#include osgDB/Registry
#include osgDB/WriteFile
#include osg/Notify
using namespace std;
using namespace osg;
#define ImageWidth 64
#define ImageHeight 64
GLubyte checkImage[64*64][4];
osg::ref_ptrosg::Image image;
osg::Texture2D *rendTexture;
osg::ref_ptrosg::Camera mPreRenderCamera;
void makeCheckImage(void);
osg::ref_ptrosg::Node createSceneGraph(void);
void createTexture(const unsigned int,const unsigned int);
void textureCamera();
int main()
{
osgViewer::Viewer viewer;
// renderTexture();
//osg::ref_ptrosg::Node scene=createSceneGraph();
//createTexture(ImageWidth,ImageHeight);
textureCamera();
osg::ref_ptrosg::Group root=new osg::Group;
osg::ref_ptrosg::MatrixTransform mTransform=new osg::MatrixTransform ;
osg::ref_ptrosg::Geode geode=new osg::Geode;
osg::ref_ptrosg::Geometry geom=new osg::Geometry;
osg::ref_ptrosg::Vec3Array ary=new osg::Vec3Array;
ary-push_back(osg::Vec3(-100.0,0.0,-100.0));
ary-push_back(osg::Vec3(100.0,0.0,-100.0));
ary-push_back(osg::Vec3(100.0,0.0,100.0));
ary-push_back(osg::Vec3(-100.0,0.0,100.0));
geom-setVertexArray(ary.get());
osg::ref_ptrosg::Vec4Array col=new osg::Vec4Array;
geom-setColorBinding(osg::Geometry::BIND_PER_VERTEX);
col-push_back(osg::Vec4(1.0,1.0,1.0,1.0));
col-push_back(osg::Vec4(1.0,1.0,1.0,1.0));
col-push_back(osg::Vec4(1.0,1.0,1.0,1.0));
col-push_back(osg::Vec4(1.0,1.0,1.0,1.0));
geom-setColorArray(col.get());
osg::ref_ptrosg::Vec3Array n=new osg::Vec3Array;
geom-setColorBinding(osg::Geometry::BIND_OVERALL);
n-push_back(osg::Vec3(0.0,-1.0,0.0));
geom-setNormalArray(n.get());
osg::ref_ptrosg::StateSet ss1=geode-getOrCreateStateSet();
osg::ref_ptrosg::Vec2Array tex1=new osg::Vec2Array;
tex1-push_back(osg::Vec2(0.0,0.0));
tex1-push_back(osg::Vec2(1.0,0.0));
tex1-push_back(osg::Vec2(1.0,1.0));
tex1-push_back(osg::Vec2(0.0,1.0));
geom-setTexCoordArray(0,tex1.get());
/*int c;
for (int i = 0; i ImageHeight; i++)
for (int j = 0; j ImageWidth; j++)
{
c = (((i0x8)==0)^((j0x8)==0))*255;
checkImage[i][j][0] = (GLubyte) c;
checkImage[i][j][1] = (GLubyte) c;
checkImage[i][j][2] = (GLubyte) c;
checkImage[i][j][3] = (GLubyte) 255;
}
//osg::ref_ptrosg::Image image=new osg::Image;
//image-setImage(64,64,1,4,GL_RGBA,GL_UNSIGNED_BYTE,(unsigned char*)checkImage,osg::Image::USE_NEW_DELETE);
*/
//osg::ref_ptrosg::Image image = osgDB::readImageFile( texture.jpg );
// Attach the image in a Texture2D object
//osg::ref_ptrosg::Texture2D tex = new osg::Texture2D;
//tex-setImage( image.get() );
ss1-setTextureAttributeAndModes( 0,rendTexture,osg::StateAttribute::ON);
coutTexture widthrendTexture-getTextureWidth()endl;
coutTexture HeightrendTexture-getTextureHeight()endl;
/*
osg::DrawElementsUInt* t1 =
new osg::DrawElementsUInt(osg::PrimitiveSet::TRIANGLES, 0);
t1-push_back(0);
t1-push_back(1);
t1-push_back(2);
geom-addPrimitiveSet(t1);
osg::DrawElementsUInt* t2 =
new osg::DrawElementsUInt(osg::PrimitiveSet::TRIANGLES, 0);
t2-push_back(2);
t2-push_back(3);
t2-push_back(1);
geom-addPrimitiveSet(t2);
geode-addDrawable(geom.get());
*/
geom-addPrimitiveSet(new osg::DrawArrays( osg::PrimitiveSet::QUADS, 0, 4
Re: [osg-users] Loading an osg::Image using setImage
Hi,
other ways of flipping:
* use osg::Image's flipVertical()
* just flip the texture coordinates
rgds
jp
Andrew Burnett-Thompson wrote:
Hmm, well that was easy!
The flipping of rows worked fine, to set the image I used GL_BGR for
pixel format only, keeping GL_RGB as internal pixel format (else I got a
gray square).
Thank you for an extremely helpful response :)
Andrew
On Thu, Aug 20, 2009 at 6:15 PM, Farshid Lashkari fla...@gmail.com
mailto:fla...@gmail.com wrote:
Hi Andrew,
It looks like the original bitmap is in BGR format, so you will
probably need to use the GL_BGR pixel format when calling
setImage(). To unflip the image it seems like you can iterate
backwards over the source image inside your copy loop:
ptrSourceRow = ptrSrcImage + ( (iHeight - 1 - i) * iStride);
I believe this should fix your problems.
Cheers,
Farshid
On Thu, Aug 20, 2009 at 9:46 AM, Andrew Thompson
andyb1...@yahoo.co.uk mailto:andyb1...@yahoo.co.uk wrote:
Hi there,
I am trying to load an osg::Image using the setImage method -
inparticular I am copying a Managed bitmap
(System.Drawing.Bitmap) to the osg::Image to use it as a texture
map.
As you can see I'm having a few problems. Here's the osg::Image
texture mapped onto a quad when I load it in from file using
osgDB::readImageFile
[Image:
http://i137.photobucket.com/albums/q217/andyb1979/tquadreadimage.png
]
Here's the same textured quad, but the osg::Image was created
using setImage and a copy from a managed bitmap
[Image:
http://i137.photobucket.com/albums/q217/andyb1979/th_tquadsetimage.png
]
As you can see the image seems to have been inverted and flipped!
Here is my code to convert a managed bitmap to osg::Image. The
input bitmap has been loaded from file, is in the format 24bpp RGB.
I know I'm getting the size/bits per pixel right as the output
osg::Image is the right shape and size, with no tearing. However
I don't know why the image is inverted!
Code:
osg::ref_ptrosg::Image
SceneUtil::ManagedBitmapToOSGImage(System::Drawing::Bitmap ^ bitmap)
{
//
// Check params
//
if (bitmap == nullptr)
{
throw gcnew Exception(Unable to convert
System::Drawing::Bitmap to osg::Image as the input image is null);
}
if (bitmap-PixelFormat !=
System::Drawing::Imaging::PixelFormat::Format24bppRgb)
{
throw gcnew Exception(Unable to convert
System::Drawing::Bitmap to osg::Image as the input image must be
in the format Format24bppRgb);
}
// Create a new OSG Image
osg::ref_ptrosg::Image image = new osg::Image();
System::Drawing::Imaging::BitmapData ^ bitmapData =
bitmap-LockBits(
System::Drawing::Rectangle(0, 0, bitmap-Width,
bitmap-Height),
System::Drawing::Imaging::ImageLockMode::ReadOnly,
System::Drawing::Imaging::PixelFormat::Format24bppRgb);
// Create data to hold the destination image
BYTE * ptrSrcImage = (BYTE*)bitmapData-Scan0.ToPointer();
BYTE * ptrDestImage = new unsigned char [bitmap-Width *
bitmap-Height * 3];
BYTE * ptrSourceRow = nullptr;
BYTE * ptrDestRow = nullptr;
int iWidth = bitmapData-Width;
int iHeight = bitmapData-Height;
int iStride = bitmapData-Stride;
// Copy the System::Drawing::Bitmap instance over line by
line - this gets around the
// lack of stride support in the osg::Image.
for(int i = 0; i iHeight; i++)
{
// Get the source row pointer
ptrSourceRow = ptrSrcImage + (i * iStride);
// Get the destination row pointer
ptrDestRow = ptrDestImage + (i * (iWidth * 3));
// Copy the source row to the destination row
memcpy(ptrDestRow, ptrSourceRow, iWidth * 3);
}
// Set the data on the osg::Image
image-setImage(
bitmap-Width,
bitmap-Height,
1,
GL_RGB,
GL_RGB,
GL_UNSIGNED_BYTE,
ptrDestImage,
osg::Image::USE_NEW_DELETE);
bitmap-UnlockBits(bitmapData);
return image;
}
Any ideas?
Thank you!
Andrew
--
Re: [osg-users] 3DS loader revisited?
Hi Robert, Of course, my goal is to work on the 3DS reader/writer without loosing functionality. Actually, I simply tried to replace the old lib3DS with the new one... and it was very straightforward: some calls were renamed, some others changed a bit... Anyway I could load my 3DS models exactly the same way I did before. I could even remove a tiny limitation (meshes were taversed by name, which can be dangerous if two identical names exist. That should not, but now it's okay). Everything worked like a charm! I guess some testing would be a good idea, but it seems there was no functionality loss. Side note: I had a few compilation errors using VC9 in the lib3DS, because of implicit conversions from void* to SomethingElse*. I made those conversions explicit and gave the fix to the lib3DS patches tracker. About linking, I guess putting lib3DS as a static library could be a good idea, even if my testing was with direct inclusion of source files. I'll work on it and submit VC (8? 9?) binaries I guess... or may I keep the files as they are in a first time? About the writer, well, we have some customers with old software... Moreover they're absolutely not 3D/vis/sim-oriented, so there are few supported formats. I agree 3DS is very poor, but it is a non-flexible format (as some XML-based formats could be); and as a non-flexible format it can be loaded exactly the same way on various (old) software. What kind of output format would you use else? Collada? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Mail Original - De: Robert Osfield robert.osfi...@gmail.com À: OpenSceneGraph Users osg-users@lists.openscenegraph.org Envoyé: Jeudi 20 Août 2009 17h12:25 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [osg-users] 3DS loader revisited? Hi Sukender, On Thu, Aug 20, 2009 at 3:57 PM, Sukendersuky0...@free.fr wrote: Good news! I've sync'd the 3DS reader with lib3DS 2.0.0-rc1 (well, I need to modify the CMakeList now). I'm not 100% sure that the one I used ( http://www.lib3ds.org/ ) is the same as the one used in OSG... Am I wrong ? If not, is it a problem ? I believe it's probaby the same lib3ds, it's quite a few years since I reviewed the original source though. You should be able to spot similarities with the existing code base. Just adopting lib3ds won't carry the modifications that have been made by members of the OSG community so support reading for istreams etc, so I don't think a straight adoption of lib3ds will be possible without modifications of lib3ds or our plugin. I'm opposed to adopting any new code that drops existing functionality, the existing functionality is being actively used by members of the community. While 3ds write hasn't been up to now a requirement. Should the lib3DS files be in osgPlugins/3ds, or osgPlugins/3ds/lib3DS, or simply oustide as an external dependency to make sync easier? I've original put lib3ds into the 3ds plugin directory just to enable easy build for OSG users. These days with CMake building against 3rd party dependencies is less onerous, so potentially would could spin it out. The bottom line is the ability to support all that is supported by the existing plugin. Once cleaned and submitted, I'll work on the 3DS writer, as told in another thread. So are you porting the existing plugin across to use the external lib3ds, writing a new plugin from scratch, adapting the new lib3ds to be closer to what we have? I'm curious as to why writing to .3ds is a goal, as a exchange format it's pretty poor. 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] Compress image
Hi All,i decided to use a tool for this purpose. now i am lazy to integrate
a scaling function into my code..
i found ImageMagick and i will use converter.exe of this library.
now i changed my function like:
///
void simUtil::SimImageUtils::scaleAndSaveImage( osg::Image* image, float
scaleFactor, const std::string outputFilename )
{
std::ostringstream command;
command converter.exe image-getFileName() -resize
image-s() * scaleFactor image-t() * scaleFactor
outputFilename;
system(command.str().c_str());
}
///
thanks to all...
On Fri, Aug 21, 2009 at 9:12 AM, J.P. Delport jpdelp...@csir.co.za wrote:
Hi Ufuk,
Ufuk wrote:
actually i just want to have a scale code of image..
half and quarter resolution would be enough for me.. i wanted to scale
them when i create terrain.
if you are working with terrain I would suggest you also look at the GDAL
functions/lib. E.g. have a look at the gdaladdo man page, it is a command
line app that builds overview images, but you could use the same
functionality directly from your application if you link to GDAL. You might
also find some other helpful functions.
jp
i have a terrain editor and viewer which are 2 separate programs.
on editor, in saving process, i want to store lower resolution textures
too and i wanted to create in my program.
my terrain viewer program will load all textures and use low resolution
textures for pages which are far away from the camera..
i don't want to use .dds because in terrain editor, user can use any
texture he wants. so i don't want to give up texture selection dynamism
here.. i can't limit users just with my textures which are selected before.
On Thu, Aug 20, 2009 at 5:58 PM, Ümit Uzun umituzu...@gmail.com mailto:
umituzu...@gmail.com wrote:
Hi Ufuk;
If you want to create mippaped images on your disk instead of
programmaticaly. I suggest you to use GIMP to mipmap(rescale each
different resolution image separately) and when you need you can
call related resolution image :)
Is this your expected or you want to create one image which has all
resoluted images in it? If you want kind of this operation you can
use dds format. But I don't know osg does support reading mipmapped
dds format.
Regards.
Ümit Uzun
2009/8/20 Ufuk ufuk@gmail.com mailto:ufuk@gmail.com
Hi Ümit,
yes, i need mipmapping but i want to store these mipmapped
textures on disk. i dont want so many calculations on rendering...
so i wanted to store these images on disk.
do you know a way to do this or i should write a code?
On Thu, Aug 20, 2009 at 5:43 PM, Ümit Uzun umituzu...@gmail.com
mailto:umituzu...@gmail.com wrote:
Hi Ufuk;
Compress word doesn't define your expected operation very
well. This operation's name is Mipmapping. You should
generate automatic mipmapping for your texture in runtime
and the you can choose any resolution you have created to
use your program.
Regards.
Ümit Uzun
2009/8/20 Ufuk ufuk@gmail.com mailto:ufuk@gmail.com
is there any function that compress image in osg?
for example i have an 256x256 image and i want to
compress it to 128x128 or 64x64...
i checked for osg::Image::scaleImage() but it did not
change the resolution.. maybe i did something wrong?
Here is the code:
///
void simUtil::SimImageUtils::scaleAndSaveImage(
osg::Image* image, float scaleFactor, const std::string
filename )
{
osg::ref_ptrosg::Image cImage = new
osg::Image(*image);
cImage-scaleImage(image-s() * scaleFactor,
image-t() * scaleFactor, image-r() * scaleFactor);
osgDB::writeImageFile(*image, filename);
}
///
--Ufuk
___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
Re: [osg-users] osg Manipulator example problem
Hi Markus, These methods are in the svn/trunk version of the OSG/osgManipulator, so clearly you must be looking at the svn/trunk version of the osgmanipulator. Please match the version of the examples against the version of the OSG your have. The two come together so it should be straight forward to avoid problems. Robert. On Thu, Aug 20, 2009 at 10:56 PM, Markus Husseinimar...@husseini.de wrote: Hi, i have included the code of the osg Manipulator Example from openscenegraph.org. But if i try to compile my code i get some errors, that - addTransformUpdating - setHandleEvents - setActivationModKeyMask - setActivationKeyEvent are no Elements of osgManipulator::Dragger!? Does I need an include? but witch one? or they are custom Elements? Thank you! Cheers, Markus -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16514#16514 ___ 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] 3DS loader revisited?
Hi Sukender, On Fri, Aug 21, 2009 at 8:35 AM, Sukendersuky0...@free.fr wrote: Of course, my goal is to work on the 3DS reader/writer without loosing functionality. Actually, I simply tried to replace the old lib3DS with the new one... and it was very straightforward: some calls were renamed, some others changed a bit... One areas of significant deviation was for the support of reading from istreams, in your work can you still read from istreams? The ability to read from istream enables reading from http via the curl plugin. Anyway I could load my 3DS models exactly the same way I did before. I could even remove a tiny limitation (meshes were taversed by name, which can be dangerous if two identical names exist. That should not, but now it's okay). Everything worked like a charm! I guess some testing would be a good idea, but it seems there was no functionality loss. Side note: I had a few compilation errors using VC9 in the lib3DS, because of implicit conversions from void* to SomethingElse*. I made those conversions explicit and gave the fix to the lib3DS patches tracker. I had to make a number of changes to fix the pedantic warnings emitted by g++ 4.x. This might need to be rolled in as well. About linking, I guess putting lib3DS as a static library could be a good idea, even if my testing was with direct inclusion of source files. I'll work on it and submit VC (8? 9?) binaries I guess... or may I keep the files as they are in a first time? We could possibly just include the source to lib3ds as a subdirectory of the 3ds plugin, as CMake allows us to manage the source directories better than the old days of trying to support both VS6 and Makefiles. About the writer, well, we have some customers with old software... Moreover they're absolutely not 3D/vis/sim-oriented, so there are few supported formats. I agree 3DS is very poor, but it is a non-flexible format (as some XML-based formats could be); and as a non-flexible format it can be loaded exactly the same way on various (old) software. What kind of output format would you use else? Collada? A major problem with 3ds is that because there is no official/public specification and lots of different attempts at implementations the files generated can be very patchy in the their consistency. 3ds is not likely to map a general purpose scene graph too well either, but this issue applies to most writers - a general purpose scene graph is far to flexible to be easily mapped by the constraints of most formats. Collada has to be one of the best for being able to map things, but even it is a long way from perfect. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg Manipulator example problem
Hi, thanks for your answer, but I think i am to stupid to find the svn/trunk version version. Can u give me a link pls. :? Thank you! Cheers, Markus -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16532#16532 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FBOs without color or depth attachments /DrawBuffer/ ReadBuffer
Hi Wojtek, I have now merged your changes and the merge when smoothly, and changes all look reasonable, so thumbs up there. In testing I found problems with: osgshadow -4 --lispsm As no shadow was rendered, this is with my Ati 4650 + ATI Linux drivers. If I re-enabled the forcing on of the colour attachment via: #define FORCE_COLOR_ATTACHMENT 1 And then recompiled, then osgshadow with lispsm worked once more. This looks to be a driver bug, and I'll go chase up a more recent driver to see if fixes things, but there is chance that it won't, which leaves in the position of deciding what to do - end users of our applications don't have the luxury of recompiling the OSG to fix it for a particular bit of hardware/driver version, so we need to look at runtime scheme for tuning things. Thoughts? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg Manipulator example problem
Hi Markus, On Fri, Aug 21, 2009 at 9:28 AM, Markus Husseinimar...@husseini.de wrote: thanks for your answer, but I think i am to stupid to find the svn/trunk version version. Can u give me a link pls. :? No I won't answer you, as you really do need to put in a bit more effort when investigating things, if you don't learn this skill we'll have to walk you through writing every single line of your code. I'll give you a hint though... download page. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3DS loader revisited?
Hi Robert, I must admit I didn't test istreams. I'll do that testing. Do you think testing with a ifstream is enough, or must I test with HTTP (since I'm not sure I compiled with curl)? I'll also fix the warnings I found (most of them are conversion from X to Y: possible loss of data). Making lib3DS a subproject of the 3DS plugin sounds fine to me. And as a final note, I must say I don't have to export a true and full-featured scene graph, but a few simple objects. This is why the 3DS suits that goal with older software. I'll tell you about istream reading soon I hope. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Mail Original - De: Robert Osfield robert.osfi...@gmail.com À: OpenSceneGraph Users osg-users@lists.openscenegraph.org Envoyé: Vendredi 21 Août 2009 10h22:42 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [osg-users] 3DS loader revisited? Hi Sukender, On Fri, Aug 21, 2009 at 8:35 AM, Sukendersuky0...@free.fr wrote: Of course, my goal is to work on the 3DS reader/writer without loosing functionality. Actually, I simply tried to replace the old lib3DS with the new one... and it was very straightforward: some calls were renamed, some others changed a bit... One areas of significant deviation was for the support of reading from istreams, in your work can you still read from istreams? The ability to read from istream enables reading from http via the curl plugin. Anyway I could load my 3DS models exactly the same way I did before. I could even remove a tiny limitation (meshes were taversed by name, which can be dangerous if two identical names exist. That should not, but now it's okay). Everything worked like a charm! I guess some testing would be a good idea, but it seems there was no functionality loss. Side note: I had a few compilation errors using VC9 in the lib3DS, because of implicit conversions from void* to SomethingElse*. I made those conversions explicit and gave the fix to the lib3DS patches tracker. I had to make a number of changes to fix the pedantic warnings emitted by g++ 4.x. This might need to be rolled in as well. About linking, I guess putting lib3DS as a static library could be a good idea, even if my testing was with direct inclusion of source files. I'll work on it and submit VC (8? 9?) binaries I guess... or may I keep the files as they are in a first time? We could possibly just include the source to lib3ds as a subdirectory of the 3ds plugin, as CMake allows us to manage the source directories better than the old days of trying to support both VS6 and Makefiles. About the writer, well, we have some customers with old software... Moreover they're absolutely not 3D/vis/sim-oriented, so there are few supported formats. I agree 3DS is very poor, but it is a non-flexible format (as some XML-based formats could be); and as a non-flexible format it can be loaded exactly the same way on various (old) software. What kind of output format would you use else? Collada? A major problem with 3ds is that because there is no official/public specification and lots of different attempts at implementations the files generated can be very patchy in the their consistency. 3ds is not likely to map a general purpose scene graph too well either, but this issue applies to most writers - a general purpose scene graph is far to flexible to be easily mapped by the constraints of most formats. Collada has to be one of the best for being able to map things, but even it is a long way from perfect. 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
[osg-users] Texturing Operation on osg::Cylinder ShapeDrawable Problem.
Hi All; If this is much simple question please forgive me :D I am trying to create wheel body and related texture by using ShapeDrawable and can't. Do I have to use Modeling tools to create my expected looking images as you can see from attached image? Or Do I have to manipulate texture coordinate by programmatically at runtime? What should I do? I can create this wheel easly by using Blender but I want to create by coding. ExpectedWheel part had created on DirectX by using same wheel texture. My Code: // Wheel osg::ref_ptrosg::Geode wheelGeode = new osg::Geode(); wheelGeode-addDrawable(new osg::ShapeDrawable(new osg::Cylinder(osg::Vec3(0.0, 0.0, 0.0), RADIUS, 0.08))); osg::ref_ptrosg::Texture2D texWheel = new osg::Texture2D(); texWheel-setImage(osgDB::readImageFile(./Data/wheel.bmp)); wheelGeode-getOrCreateStateSet()-setTextureAttributeAndModes(0, texWheel.get(), osg::StateAttribute::ON); Regards. Ümit Uzun attachment: Wheel.jpg___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texturing Operation on osg::Cylinder ShapeDrawable Problem.
Hi Umit, The osg::Shapes/osg::ShapeDrawable really aren't written to be used for general geometry/scene construction. osg::Shape exist to help with defining primitive shapes for physics modeling, and the ShapeDrawable as a just a convenience method to help visualize them. The tool to use is osg::Geometry as it will give you complete flexibility. See the osggeometry example. Robert. On Fri, Aug 21, 2009 at 10:09 AM, Ümit Uzunumituzu...@gmail.com wrote: Hi All; If this is much simple question please forgive me :D I am trying to create wheel body and related texture by using ShapeDrawable and can't. Do I have to use Modeling tools to create my expected looking images as you can see from attached image? Or Do I have to manipulate texture coordinate by programmatically at runtime? What should I do? I can create this wheel easly by using Blender but I want to create by coding. ExpectedWheel part had created on DirectX by using same wheel texture. My Code: // Wheel osg::ref_ptrosg::Geode wheelGeode = new osg::Geode(); wheelGeode-addDrawable(new osg::ShapeDrawable(new osg::Cylinder(osg::Vec3(0.0, 0.0, 0.0), RADIUS, 0.08))); osg::ref_ptrosg::Texture2D texWheel = new osg::Texture2D(); texWheel-setImage(osgDB::readImageFile(./Data/wheel.bmp)); wheelGeode-getOrCreateStateSet()-setTextureAttributeAndModes(0, texWheel.get(), osg::StateAttribute::ON); Regards. Ümit Uzun ___ 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] Compress image
Hi Ufuk,
disregarding the follow-ups regarding mipmapping:
you're saving the original image. The scaled down image is 'cimage', not the original
'image'. Change the 'writeImageFile' to use 'cimage' and you should be good.
Cheers,
/uli
On 20/08/09 4:39 PM, Ufuk wrote:
is there any function that
com/
void simUtil::SimImageUtils::scaleAndSaveImage( osg::Image* image, float
scaleFactor, const std::string filename )
{
osg::ref_ptrosg::Image cImage = new osg::Image(*image);
cImage-scaleImage(image-s() * scaleFactor, image-t() * scaleFactor,
image-r() * scaleFactor);
osgDB::writeImageFile(*image, filename);
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texturing Operation on osg::Cylinder ShapeDrawable Problem.
Hi Robert; Thanks for reply. I have known ShapeDrawable's main target is creating faster general shape for scene construction :) I will try to create my wheel by Geometry class. Regards. Ümit Uzun 2009/8/21 Robert Osfield robert.osfi...@gmail.com Hi Umit, The osg::Shapes/osg::ShapeDrawable really aren't written to be used for general geometry/scene construction. osg::Shape exist to help with defining primitive shapes for physics modeling, and the ShapeDrawable as a just a convenience method to help visualize them. The tool to use is osg::Geometry as it will give you complete flexibility. See the osggeometry example. Robert. On Fri, Aug 21, 2009 at 10:09 AM, Ümit Uzunumituzu...@gmail.com wrote: Hi All; If this is much simple question please forgive me :D I am trying to create wheel body and related texture by using ShapeDrawable and can't. Do I have to use Modeling tools to create my expected looking images as you can see from attached image? Or Do I have to manipulate texture coordinate by programmatically at runtime? What should I do? I can create this wheel easly by using Blender but I want to create by coding. ExpectedWheel part had created on DirectX by using same wheel texture. My Code: // Wheel osg::ref_ptrosg::Geode wheelGeode = new osg::Geode(); wheelGeode-addDrawable(new osg::ShapeDrawable(new osg::Cylinder(osg::Vec3(0.0, 0.0, 0.0), RADIUS, 0.08))); osg::ref_ptrosg::Texture2D texWheel = new osg::Texture2D(); texWheel-setImage(osgDB::readImageFile(./Data/wheel.bmp)); wheelGeode-getOrCreateStateSet()-setTextureAttributeAndModes(0, texWheel.get(), osg::StateAttribute::ON); Regards. Ümit Uzun ___ 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
Re: [osg-users] FBOs without color or depth attachments /DrawBuffer/ ReadBuffer
Hi Wojtek et. al, I have just checked in the changes but to avoid regression on some users systems I've temporarily reverted the disabling of the forcing on of colour and depth buffer. But setting: #define FORCE_COLOR_ATTACHMENT 1 #define FORCE_DEPTH_ATTACHMENT 1 At the top of src/osgUtil/RenderStage. I say temporarily as I believe we'll need to come up with a runtime override scheme that allows users to set the defaults for the above at runtime, perhaps via the the standard osg::DisplaySettings class that is used right now for various global settings, with env vars available to customize the defaults. It could be that we need to come up with a simple file format for specifying these types defaults for various hardware/OS targets, and make it possible to load this file at runtime to configure things. This is a more general issue than just FBOs, but this FBO issue is probably a good catlyst for getting some kind of solution. Thoughts? Suggestions? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texturing Operation on osg::Cylinder ShapeDrawable Problem.
Hi Umit, On Fri, Aug 21, 2009 at 10:34 AM, Ümit Uzunumituzu...@gmail.com wrote: Thanks for reply. I have known ShapeDrawable's main target is creating faster general shape for scene construction :) They make it fast to write the code simple scenes, but they slow at runtime, both for rendering and intersection tests. I will try to create my wheel by Geometry class. Once you learn about creating osg::Geometry you'll be well set for the rest of your career of using the OSG. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg Manipulator example problem
Hi, Sorry if u thinking I dont search for that. And yes I know the Downloadpage but the version i found there doesnt work. http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/examples/osgmanipulator/osgmanipulator.cpp And I only find this and nothing else. Thank you! Cheers, Markus -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16545#16545 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3DS loader revisited?
Hi Sukender Robert, Just to emphasise what has already been said really, but we have literally 10's of thousands of 3DS models for various manufacturer's products, so whilst I accept there are significant limitations with 3DS structure now compared to more modern formats, the sheer size of the back catalogue means it will be around for a long time to come. Hence I think support for 3DS is important within OSG. Robert's comments about the 3DS reader supporting streams is vital for us now with our web based catalogue viewing system. In regards to the ability to write a 3DS file, this would be fantastic. If help/assistance/testing is wanted I'm sure I'd be able to find some time. If you need sample models these could probably be provided as well. In regards to Collada, my recent excursions into conversions from 3DS to collada via osg has had mixed results. Still investigating (when time permits) but there is certainly an issue in validity of the collada file produced if the node name of the scene graph has spaces, also issues encountered with materials. However, these are for another thread. But I tend to agree that even with the teething problems, Collada does look to be very powerful. Is anyone looking at the new Autocad format - FBX? Just wondering whether anyone considering a Reader/Writer for it? Looked at trying to take an OSG collada file and convert it to FBX via Autocad's converter, but it failed. End of memory dump :-) Kind regards Neil. Robert Osfield robert.osfi...@gmail.com wrote: Hi Sukender, On Fri, Aug 21, 2009 at 8:35 AM, Sukendersuky0...@free.fr wrote: Of course, my goal is to work on the 3DS reader/writer without loosing functionality. Actually, I simply tried to replace the old lib3DS with the new one... and it was very straightforward: some calls were renamed, some others changed a bit... One areas of significant deviation was for the support of reading from istreams, in your work can you still read from istreams? The ability to read from istream enables reading from http via the curl plugin. Anyway I could load my 3DS models exactly the same way I did before. I could even remove a tiny limitation (meshes were taversed by name, which can be dangerous if two identical names exist. That should not, but now it's okay). Everything worked like a charm! I guess some testing would be a good idea, but it seems there was no functionality loss. Side note: I had a few compilation errors using VC9 in the lib3DS, because of implicit conversions from void* to SomethingElse*. I made those conversions explicit and gave the fix to the lib3DS patches tracker. I had to make a number of changes to fix the pedantic warnings emitted by g++ 4.x. This might need to be rolled in as well. About linking, I guess putting lib3DS as a static library could be a good idea, even if my testing was with direct inclusion of source files. I'll work on it and submit VC (8? 9?) binaries I guess... or may I keep the files as they are in a first time? We could possibly just include the source to lib3ds as a subdirectory of the 3ds plugin, as CMake allows us to manage the source directories better than the old days of trying to support both VS6 and Makefiles. About the writer, well, we have some customers with old software... Moreover they're absolutely not 3D/vis/sim-oriented, so there are few supported formats. I agree 3DS is very poor, but it is a non-flexible format (as some XML-based formats could be); and as a non-flexible format it can be loaded exactly the same way on various (old) software. What kind of output format would you use else? Collada? A major problem with 3ds is that because there is no official/public specification and lots of different attempts at implementations the files generated can be very patchy in the their consistency. 3ds is not likely to map a general purpose scene graph too well either, but this issue applies to most writers - a general purpose scene graph is far to flexible to be easily mapped by the constraints of most formats. Collada has to be one of the best for being able to map things, but even it is a long way from perfect. 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] 3DS loader revisited?
Hi Neil, Thanks for your proposal! I'm pretty sure I'll ask you to test the 3DS stream read, and the writer, once submitted. About Collada, I had some feedback that roughly says powerful but never interpreted the same way, depending on the software... is that really true? About FBX, I'm not sure it could be integrated as-is in OSG... Did someone investigate? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - neil hughes neil.hug...@tesco.net a écrit : Hi Sukender Robert, Just to emphasise what has already been said really, but we have literally 10's of thousands of 3DS models for various manufacturer's products, so whilst I accept there are significant limitations with 3DS structure now compared to more modern formats, the sheer size of the back catalogue means it will be around for a long time to come. Hence I think support for 3DS is important within OSG. Robert's comments about the 3DS reader supporting streams is vital for us now with our web based catalogue viewing system. In regards to the ability to write a 3DS file, this would be fantastic. If help/assistance/testing is wanted I'm sure I'd be able to find some time. If you need sample models these could probably be provided as well. In regards to Collada, my recent excursions into conversions from 3DS to collada via osg has had mixed results. Still investigating (when time permits) but there is certainly an issue in validity of the collada file produced if the node name of the scene graph has spaces, also issues encountered with materials. However, these are for another thread. But I tend to agree that even with the teething problems, Collada does look to be very powerful. Is anyone looking at the new Autocad format - FBX? Just wondering whether anyone considering a Reader/Writer for it? Looked at trying to take an OSG collada file and convert it to FBX via Autocad's converter, but it failed. End of memory dump :-) Kind regards Neil. Robert Osfield robert.osfi...@gmail.com wrote: Hi Sukender, On Fri, Aug 21, 2009 at 8:35 AM, Sukendersuky0...@free.fr wrote: Of course, my goal is to work on the 3DS reader/writer without loosing functionality. Actually, I simply tried to replace the old lib3DS with the new one... and it was very straightforward: some calls were renamed, some others changed a bit... One areas of significant deviation was for the support of reading from istreams, in your work can you still read from istreams? The ability to read from istream enables reading from http via the curl plugin. Anyway I could load my 3DS models exactly the same way I did before. I could even remove a tiny limitation (meshes were taversed by name, which can be dangerous if two identical names exist. That should not, but now it's okay). Everything worked like a charm! I guess some testing would be a good idea, but it seems there was no functionality loss. Side note: I had a few compilation errors using VC9 in the lib3DS, because of implicit conversions from void* to SomethingElse*. I made those conversions explicit and gave the fix to the lib3DS patches tracker. I had to make a number of changes to fix the pedantic warnings emitted by g++ 4.x. This might need to be rolled in as well. About linking, I guess putting lib3DS as a static library could be a good idea, even if my testing was with direct inclusion of source files. I'll work on it and submit VC (8? 9?) binaries I guess... or may I keep the files as they are in a first time? We could possibly just include the source to lib3ds as a subdirectory of the 3ds plugin, as CMake allows us to manage the source directories better than the old days of trying to support both VS6 and Makefiles. About the writer, well, we have some customers with old software... Moreover they're absolutely not 3D/vis/sim-oriented, so there are few supported formats. I agree 3DS is very poor, but it is a non-flexible format (as some XML-based formats could be); and as a non-flexible format it can be loaded exactly the same way on various (old) software. What kind of output format would you use else? Collada? A major problem with 3ds is that because there is no official/public specification and lots of different attempts at implementations the files generated can be very patchy in the their consistency. 3ds is not likely to map a general purpose scene graph too well either, but this issue applies to most writers - a general purpose scene graph is far to flexible to be easily mapped by the constraints of most formats. Collada has to be one of the best for being able to map things, but even it is a long way from perfect. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg Manipulator example problem
Ok I found what you mean. I thought the src and headers are the same like the SDK. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16550#16550 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg Manipulator example problem
Hi Markus, you also need the files this file depends on, so you have to get the whole trunk repository: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk OpenSceneGraph jp Markus Husseini wrote: Hi, Sorry if u thinking I dont search for that. And yes I know the Downloadpage but the version i found there doesnt work. http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/examples/osgmanipulator/osgmanipulator.cpp And I only find this and nothing else. Thank you! Cheers, Markus -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16545#16545 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg Manipulator example problem
Hi, thanks but for my understanding is the trunk version a other SDK as the 2.8.2 and why there are 2 different sdks? Markus -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16553#16553 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg Manipulator example problem
Hi Markus, On Fri, Aug 21, 2009 at 12:34 PM, Markus Husseinimar...@husseini.de wrote: thanks but for my understanding is the trunk version a other SDK as the 2.8.2 and why there are 2 different sdks? You need to spend some time learning about subversion + version control in general. trunk is a standard term used to describe the main version of software that is being actively worked upon. The stable and developers releases are branched off the trunk. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3DS loader revisited?
FBX reader is coming very soon... :) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3DS loader revisited?
True? I'm *very* interested... But, what do you mean by very soon? Weeks? Days?... Hours? ;) Do you need any help for testing, coding...? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Michael Platings mplati...@gmail.com a écrit : FBX reader is coming very soon... :) ___ 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] 3DS loader revisited?
Side-question: is the writer on rails too? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Sukender suky0...@free.fr a écrit : True? I'm *very* interested... But, what do you mean by very soon? Weeks? Days?... Hours? ;) Do you need any help for testing, coding...? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Michael Platings mplati...@gmail.com a écrit : FBX reader is coming very soon... :) ___ 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
Re: [osg-users] FBOs without color or depth attachments/DrawBuffer/ ReadBuffer
Thanks, Robert I tested the changes on Windows and NVidia GF 8800. osghadow -4 --lispsm looked correct on my system. But I understand other systems may be different. I am curious if setting ShadowCamera-attach( COLOR_BUFFER, GL_RGB ) would have the same effect as forcing COLOR_ATTACHMENT on ATI. I suppose it should. From the former discussion with J-S I come up with opinion that the best would be to not define OSG color/depth attachment policy but put the decision on application developers. If their application is run with troublesome drivers, programmers would explicitly attach missing buffer to be sure everything works on target platform. I think that adding a line: camera-attach( COLOR_BUFFER, GL_RGB ); is as easy as changing DisplaySettings flags for FBO buffer attachment policy. On the other hand, it will also work for me if OSG majority decides to introduce such FBO attachments policy and will use DisplaySettings for this task. I have not used .cfg files and DisplaySettings extensively yet (at least not under various OSes) so I will leave question about DisplaySetting script format for more opinionated users ;-) Cheers, Wojtek - Original Message - From: Robert Osfield robert.osfi...@gmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Friday, August 21, 2009 11:39 AM Subject: Re: [osg-users] FBOs without color or depth attachments/DrawBuffer/ ReadBuffer Hi Wojtek et. al, I have just checked in the changes but to avoid regression on some users systems I've temporarily reverted the disabling of the forcing on of colour and depth buffer. But setting: #define FORCE_COLOR_ATTACHMENT 1 #define FORCE_DEPTH_ATTACHMENT 1 At the top of src/osgUtil/RenderStage. I say temporarily as I believe we'll need to come up with a runtime override scheme that allows users to set the defaults for the above at runtime, perhaps via the the standard osg::DisplaySettings class that is used right now for various global settings, with env vars available to customize the defaults. It could be that we need to come up with a simple file format for specifying these types defaults for various hardware/OS targets, and make it possible to load this file at runtime to configure things. This is a more general issue than just FBOs, but this FBO issue is probably a good catlyst for getting some kind of solution. Thoughts? Suggestions? 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] 3DS loader revisited?
Soon = now :) Testing fixing very welcome. Now osgAnimation is supported by FBX, my hope is that other people will soon add support to DAE, 3DS etc. I don't intend to do a writer, but that should be relatively easy for someone who does want to do it. FBX provides many ways to represent data, and figuring out how to adapt all those to OSG was the hard part (and I'm sure I've missed many), but I imagine going the other way (picking one way and exporting to that) would be relatively simple. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Orienting a model (matrixtrans) toward a target location?
[quote=Chris 'Xenon' Hanson]Tony Horrobin wrote: Hi Kris, Is the target moving too? Cheers, Not at the moment. Currently I'm only worried about figuring out how to orient in the right direction, I'll worry about tracking at a later time. =) Chris 'Xenon' Hanson wrote: Thrall, Bryan wrote: There's osg::Matrix::makeLookAt() Wow. if only that were named something intuitive that I would have thought to look for. Or Look At, as the case may be. ;) Does that answer your question, Kris? -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum Sort of.. that definitely looks like it's going to be what I need, but I can't seem to get it implemented properly. I've tried it this way: Code: osg::MatrixTransform* pMatTrans = dynamic_castosg::MatrixTransform*(node); osg::Matrix m = pMatTrans-getMatrix(); osg::Vec3d v = osg::Vec3d( m(3,0) , m(3,1) , m(3,2) ); // save the location for the eye point // if I understand right, the vectors in order are: eye point, lookat point, up vector, right? m.makeLookAt( v, osg::Vec3d(0.0, 0.0, 0.0), osg::Vec3d(0.0, 0.0, 1.0) ); pMatTrans-setMatrix( m ); When I run the code with this lookat call, the model is translated across the XY plane and doesn't remotely look toward 0,0,0... Prior to lookat the getMatrix call the model's getmatrix result is: Code: Stars between numbers for ease of reading... someone really needs to make up a matrix forum manipulator! =P | 1.65951e-16 * 1 * 0* 0 | | -2.47158e-15* -3.85743e-31 * 1 * 0 | | 1* -1.65951e-16 * -2.81642e-16 * 0 | | -6366.2 * 3182.6 * 3193.6* 1 | After calling makeLookAt the matrix is: Code: | -0.447157 * 0.366172 * -0.816069 * 0 | | -0.894455 * -0.183057 * 0.40797 * 0 | | 0 * 0.912364 * 0.40938 * 0 | | -1.26565e-13 * 3.71925e-13 * -7801.06 * 1 | I assume I'm simply calling something wrong somewhere... can someone point me in the right direction?[/code] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16567#16567 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Write UpdateCallbacks into an osg file ?
Hi,
I am following the Callback osg Tutorial ( Basic Tutorial on Tutorials
page ). I exchanged main to write an osg file, instead of creating a
viewer, but no UpdateCallbacks get written into my file.
How can I get UpdateCallbacks written into an osg file ?
Will such a file be properly displayed with the standard osgviewer ?
If not, how do I get Callbacks to work in a viewer written in an osg file ?
Two reference files are pasted bellow.
First my c++ code, I have commented out the original main, at the end
and added a writeFile main.
Second, a reference osg ( Animation ) file exported from Blender with
UpdateCallbacks, works properly only with the osganimationviewer.
Thanks.
Cheers, searching for the Pivot of my Soul, Peter Particle !
C++ code:
// Callback Example, Using an update callback to modify the scene graph
#include osgViewer/Viewer
#include osgGA/TrackballManipulator
#include osg/Camera
#include osg/NodeCallback
#include osg/Group
#include osg/MatrixTransform
#include osgDB/ReadFile
#include osg/Notify
#include osg/Geode
#include osg/Geometry
// Create a Quad Plane
osg::ref_ptr osg::Node createSceneGraph()
{
osg::ref_ptr osg::Group grpRoot = new osg::Group() ;
osg::ref_ptr osg::Geode geode = new osg::Geode() ;
grpRoot - addChild( geode.get() ) ;
osg::ref_ptr osg::Geometry geom = new osg::Geometry() ;
geode - addDrawable( geom.get() ) ;
osg::ref_ptr osg::Vec3Array vrts = new osg::Vec3Array() ;
geom - setVertexArray( vrts.get() ) ;
vrts - push_back( osg::Vec3( -1.f , -1.f , 0.f ) ) ;
vrts - push_back( osg::Vec3( 1.f , -1.f , 0.f ) ) ;
vrts - push_back( osg::Vec3( 1.f , 1.f , 0.f ) ) ;
vrts - push_back( osg::Vec3( -1.f , 1.f , 0.f ) ) ;
osg::ref_ptr osg::Vec4Array cols = new osg::Vec4Array() ;
geom - setColorArray( cols.get() ) ;
geom - setColorBinding( osg::Geometry::BIND_PER_VERTEX ) ;
cols - push_back( osg::Vec4( 1.f , 0.f , 0.f , 0.f ) ) ;
cols - push_back( osg::Vec4( 1.f , 1.f , 0.f , 1.f ) ) ;
cols - push_back( osg::Vec4( 0.f , 1.f , 0.f , 0.f ) ) ;
cols - push_back( osg::Vec4( 0.f , 0.f , 1.f , 0.f ) ) ;
osg::ref_ptr osg::Vec3Array nrms = new osg::Vec3Array() ;
geom - setNormalArray( nrms.get() ) ;
geom - setNormalBinding( osg::Geometry::BIND_OVERALL ) ;
nrms - push_back( osg::Vec3( 0.f , 0.f , -1.f ) ) ;
geom - addPrimitiveSet( new osg::DrawArrays(
osg::PrimitiveSet::QUADS , 0 , 4 ) ) ;
osg::StateSet * state = geom - getOrCreateStateSet() ;
state - setMode( GL_LIGHTING , osg::StateAttribute::OFF ) ;
return grpRoot.get() ;
}
class RotateCallback : public osg::NodeCallback
{
public :
RotateCallback() : _angle( 0.0 ) {}
virtual void operator()( osg::Node * node , osg::NodeVisitor *
nodeVisitor )
{
osg::MatrixTransform * transformLeft = dynamic_cast
osg::MatrixTransform * ( node ) ;
osg::Matrix matrixRotate , matrixTranslate ;
matrixTranslate.makeTranslate( -2.0 , 0.0 , 0.0 ) ;
matrixRotate.makeRotate( _angle, osg::Vec3( 0.0 , 0.0 , 1.0 ) ) ;
transformLeft - setMatrix( matrixRotate * matrixTranslate ) ;
_angle += 0.01 ;
traverse( node , nodeVisitor ) ;
}
protected :
double _angle ;
} ;
osg::Node * createScene()
{
osg::ref_ptr osg::Node plane = createSceneGraph() ;
plane - setDataVariance( osg::Object::STATIC ) ;
osg::ref_ptr osg::MatrixTransform transformLeft = new
osg::MatrixTransform ;
transformLeft - setName( Left Plane DYNAMIC ) ;
transformLeft - setDataVariance( osg::Object::DYNAMIC ) ;
transformLeft - setUpdateCallback( new RotateCallback ) ;
osg::Matrix matrixTranslate ;
matrixTranslate.makeTranslate( -2.0f , 0.0f , 0.0f ) ;
transformLeft - setMatrix( matrixTranslate ) ;
transformLeft - addChild( plane.get() ) ;
osg::ref_ptr osg::MatrixTransform transformRght = new
osg::MatrixTransform ;
transformRght - setName( Right Plane STATIC ) ;
transformRght - setDataVariance( osg::Object::STATIC ) ;
matrixTranslate.makeTranslate( 2.0f , 0.0f , 0.0f ) ;
transformRght - setMatrix( matrixTranslate ) ;
transformRght - addChild( plane.get() ) ;
osg::ref_ptr osg::Group grpRoot = new osg::Group ;
grpRoot - setName( Root Node ) ;
grpRoot - setInitialBound( osg::BoundingSphere( osg::Vec3( 0 , 0 , 6
) , 4 ) ) ;
grpRoot - setDataVariance( osg::Object::STATIC ) ;
grpRoot - addChild( transformLeft.get() ) ;
grpRoot - addChild( transformRght.get() ) ;
return( grpRoot.release() ) ;
}
/*
int main( int, char ** )
{
osgViewer::Viewer viewer ;
viewer.setSceneData( createScene() ) ;
if ( !viewer.getSceneData())
return( 1 ) ;
viewer.getCamera() - setClearColor( osg::Vec4( 0.0 , 0.0 , 0.0 , 1.0
) ) ;
return( viewer.run() ) ;
}
*/
#include osgDB/WriteFile
using std::endl ;
int main( int , char ** )
{
osg::ref_ptr osg::Node root = createScene() ;
if ( !root.valid() )
osg::notify( osg::FATAL ) Failed in createSceneGraph() !
endl ;
bool
[osg-users] Problem deploying applications with VS2005
Hi all, Just a quick note about a problem we're currently facing thanks to Microsoft. If you're working with VS2005 Express or normal edition and you've activated automatic updates, there is now a new version of the software breaking the compatibility with previous redistributable packages... You'll need to distribute new msvc*.dll files or make install the new package on the target machines : http://www.microsoft.com/downloads/details.aspx?familyid=766a6af7-ec73-40ff-b072-9112bab119c2displaylang=en Thanks to this update, we'll also need to rebuild all the 3rdparty libs if we don't want to mix the versions... Here is another link explaining how to resolve the problem if you don't want to make the jump : http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.dotnet.languages.vctid=57b1a7dd-a4b3-4e12-88be-b8942d842c85cat=en_US_73741da6-4fe1-4b05-96ce-54117b0cf52alang=encr=USsloc=en-usm=1p=1 I hope it can be useful to someone, I lost almost one work day to figure out why everything build on my machine didn't worked anymore on other machines... Cheers, -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3DS loader revisited?
I've seen your submission. I downloaded the FBX SDK, but I guess I won't work on it immediately. Maybe in 2-3 weeks? Anyway, I'll make appropriate feedback when needed. Thanks for your contribution. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Michael Platings mplati...@gmail.com a écrit : Soon = now :) Testing fixing very welcome. Now osgAnimation is supported by FBX, my hope is that other people will soon add support to DAE, 3DS etc. I don't intend to do a writer, but that should be relatively easy for someone who does want to do it. FBX provides many ways to represent data, and figuring out how to adapt all those to OSG was the hard part (and I'm sure I've missed many), but I imagine going the other way (picking one way and exporting to that) would be relatively simple. ___ 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] Orienting a model (matrixtrans) toward a target location?
[quote=omdown] Chris 'Xenon' Hanson wrote: Tony Horrobin wrote: Hi Kris, Is the target moving too? Cheers, Not at the moment. Currently I'm only worried about figuring out how to orient in the right direction, I'll worry about tracking at a later time. =) Chris 'Xenon' Hanson wrote: Thrall, Bryan wrote: There's osg::Matrix::makeLookAt() Wow. if only that were named something intuitive that I would have thought to look for. Or Look At, as the case may be. ;) Does that answer your question, Kris? -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum Sort of.. that definitely looks like it's going to be what I need, but I can't seem to get it implemented properly. I've tried it this way: Code: osg::MatrixTransform* pMatTrans = dynamic_castosg::MatrixTransform*(node); osg::Matrix m = pMatTrans-getMatrix(); osg::Vec3d v = osg::Vec3d( m(3,0) , m(3,1) , m(3,2) ); // save the location for the eye point // if I understand right, the vectors in order are: eye point, lookat point, up vector, right? m.makeLookAt( v, osg::Vec3d(0.0, 0.0, 0.0), osg::Vec3d(0.0, 0.0, 1.0) ); pMatTrans-setMatrix( m ); When I run the code with this lookat call, the model is translated across the XY plane and doesn't remotely look toward 0,0,0... Prior to lookat the getMatrix call the model's getmatrix result is: Code: Stars between numbers for ease of reading... someone really needs to make up a matrix forum manipulator! =P | 1.65951e-16 * 1 * 0* 0 | | -2.47158e-15* -3.85743e-31 * 1 * 0 | | 1* -1.65951e-16 * -2.81642e-16 * 0 | | -6366.2 * 3182.6 * 3193.6* 1 | After calling makeLookAt the matrix is: Code: | -0.447157 * 0.366172 * -0.816069 * 0 | | -0.894455 * -0.183057 * 0.40797 * 0 | | 0 * 0.912364 * 0.40938 * 0 | | -1.26565e-13 * 3.71925e-13 * -7801.06 * 1 | I assume I'm simply calling something wrong somewhere... can someone point me in the right direction?[/code] Okay an update on this, I've tried it with a far more simple example and tried working through the equations in the source code by hand... something isn't quite right somewhere and I'm not understanding what, but I come up with the same results by hand as I do using the makeLookAt... I tried just using: eye ( 0, 0, 100 ) center ( 0, 0, 0 ) up ( 0, -1, 0 ) The resulting matrix I get from this is: Code: -1 00 0 0-10 0 0 01 0 0 0 -100 0 I've stepped through the calculations the source goes through and that's all coming out the same as I get when I do it by hand, I just don't understand where those are coming from. Obviously the position vector is inverted (-100 instead of +) and for whatever reason it's not pointing at the target location... man.. so confused.. I wish I had paid better attention in linear. Hahaha. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16577#16577 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Orienting a model (matrixtrans) toward a target location?
Kris Dale wrote: I've stepped through the calculations the source goes through and that's all coming out the same as I get when I do it by hand, I just don't understand where those are coming from. Obviously the position vector is inverted (-100 instead of +) and for whatever reason it's not pointing at the target location... man.. so confused.. I wish I had paid better attention in linear. Hahaha. The only thing that crosses my mind is that makeLookAt is typically used to composed LookAt modelview matrices, not matrices for object positioning. Obviously the code must work and be right, since it's used in OSG's positioning code in several places. I'm wondering if this usage means there is some non-obvious requirements that make it unsuitable for use as an object LookAt? -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.8.2 rpms for Centos 5 and RedHat 5
Hi, results show: [r...@pciii pciii]# rpm -qa | grep curl libcurl-7.19.4-9.fc11.i586 libcurl-7.19.4-9.fc11.x86_64 curl-7.19.4-9.fc11.x86_64 [r...@pciii pciii]# Cheers, Peter -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16580#16580 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Orienting a model (matrixtrans) toward a target location?
Chris 'Xenon' Hanson wrote: Kris Dale wrote: I've stepped through the calculations the source goes through and that's all coming out the same as I get when I do it by hand, I just don't understand where those are coming from. Obviously the position vector is inverted (-100 instead of +) and for whatever reason it's not pointing at the target location... man.. so confused.. I wish I had paid better attention in linear. Hahaha. The only thing that crosses my mind is that makeLookAt is typically used to composed LookAt modelview matrices, not matrices for object positioning. Obviously the code must work and be right, since it's used in OSG's positioning code in several places. I'm wondering if this usage means there is some non-obvious requirements that make it unsuitable for use as an object LookAt? -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum Even if that were the case, looking at just the raw numbers and nothing else, it's still producing incorrect output isn't it? If I give it (0,0,100) for the eye position, shouldn't (0,0,100, 1) be the final row of the matrix rather than (0,0,-100, 1)? And what about the direction vertices? If osg::Matrix::makeLookAt doesn't work... it looks like I'm back to my original question of trying to figure out what the equations are to finding the correct vectors for x and z when I've already set the y vector to point at the the target position. Curse graphics and their reliance on linear algebra! Then again, it's better than calculus I suppose ;) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16581#16581 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Orienting a model (matrixtrans) toward a targetlocation?
Kris Dale wrote: [quote=omdown] Chris 'Xenon' Hanson wrote: Tony Horrobin wrote: Hi Kris, Is the target moving too? Cheers, Not at the moment. Currently I'm only worried about figuring out how to orient in the right direction, I'll worry about tracking at a later time. =) Chris 'Xenon' Hanson wrote: Thrall, Bryan wrote: There's osg::Matrix::makeLookAt() Wow. if only that were named something intuitive that I would have thought to look for. Or Look At, as the case may be. ;) Does that answer your question, Kris? -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum Sort of.. that definitely looks like it's going to be what I need, but I can't seem to get it implemented properly. I've tried it this way: Code: osg::MatrixTransform* pMatTrans = dynamic_castosg::MatrixTransform*(node); osg::Matrix m = pMatTrans-getMatrix(); osg::Vec3d v = osg::Vec3d( m(3,0) , m(3,1) , m(3,2) ); // save the location for the eye point // if I understand right, the vectors in order are: eye point, lookat point, up vector, right? m.makeLookAt( v, osg::Vec3d(0.0, 0.0, 0.0), osg::Vec3d(0.0, 0.0, 1.0) ); pMatTrans-setMatrix( m ); When I run the code with this lookat call, the model is translated across the XY plane and doesn't remotely look toward 0,0,0... Prior to lookat the getMatrix call the model's getmatrix result is: Code: Stars between numbers for ease of reading... someone really needs to make up a matrix forum manipulator! =P | 1.65951e-16 * 1 * 0* 0 | | -2.47158e-15* -3.85743e-31 * 1 * 0 | | 1* -1.65951e-16 * -2.81642e-16 * 0 | | -6366.2 * 3182.6 * 3193.6* 1 | After calling makeLookAt the matrix is: Code: | -0.447157 * 0.366172 * -0.816069 * 0 | | -0.894455 * -0.183057 * 0.40797 * 0 | | 0 * 0.912364 * 0.40938 * 0 | | -1.26565e-13 * 3.71925e-13 * -7801.06 * 1 | I assume I'm simply calling something wrong somewhere... can someone point me in the right direction?[/code] Okay an update on this, I've tried it with a far more simple example and tried working through the equations in the source code by hand... something isn't quite right somewhere and I'm not understanding what, but I come up with the same results by hand as I do using the makeLookAt... I tried just using: eye ( 0, 0, 100 ) center ( 0, 0, 0 ) up ( 0, -1, 0 ) The resulting matrix I get from this is: Code: -1 00 0 0-10 0 0 01 0 0 0 -100 0 I just read the man page for gluLookAt, and I think I get the problem. Hopefully, I can describe the issue adequately :-) gluLookAt (and, by extension, osg::Matrix::makeLookAt), is designed to create a ModelView matrix with the given parameters. If you know how OpenGL works, you'll understand that a modelview matrix combines the modeling matrix (which places objects in the world) with the view matrix (which places the world with respect to the view). With this in mind, the resulting matrix makes perfect sense. Think of it this way, instead of moving the viewpoint to (0, 0, 100), you keep the view at the origin and move the world to (0, 0, -100). Does that help? To get what you're looking for, you might try inverting the result of makeLookAt (not sure if this is the answer, but it could be). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Write UpdateCallbacks into an osg file ?
Peter Wrobel wrote:
Hi,
I am following the Callback osg Tutorial ( Basic Tutorial on Tutorials
page ). I exchanged "main" to write an osg file, instead of creating a
viewer, but no "UpdateCallbacks" get written into my file.
How can I get "UpdateCallbacks" written into an osg file ?
Will such a file be properly displayed with the standard osgviewer ?
If not, how do I get Callbacks to work in a viewer written in an osg
file ?
The .osg file format is extensible via a plugin mechanism. See, for
example, osgdb_osgText.
In order for standard osgviewer to load a file that contains custom
callbacks, you will need to distribute a dynamic library containing
your custom callback class, and also a dynamic plugin to support .osg
I/O for your custom class, so two dynamic libraries total.
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466
Two reference files are pasted bellow.
First my c++ code, I have commented out the original "main", at the end
and added a writeFile main.
Second, a reference osg ( Animation ) file exported from Blender with
"UpdateCallbacks", works properly only with the osganimationviewer.
Thanks.
Cheers, searching for the Pivot of my Soul, Peter Particle !
C++ code:
// Callback Example, Using an update callback to modify the scene graph
#include osgViewer/Viewer
#include osgGA/TrackballManipulator
#include osg/Camera
#include osg/NodeCallback
#include osg/Group
#include osg/MatrixTransform
#include osgDB/ReadFile
#include osg/Notify
#include osg/Geode
#include osg/Geometry
// Create a Quad Plane
osg::ref_ptr osg::Node createSceneGraph()
{
osg::ref_ptr osg::Group grpRoot = new osg::Group() ;
osg::ref_ptr osg::Geode geode = new osg::Geode() ;
grpRoot - addChild( geode.get() ) ;
osg::ref_ptr osg::Geometry geom = new osg::Geometry() ;
geode - addDrawable( geom.get() ) ;
osg::ref_ptr osg::Vec3Array vrts = new osg::Vec3Array() ;
geom - setVertexArray( vrts.get() ) ;
vrts - push_back( osg::Vec3( -1.f , -1.f , 0.f ) ) ;
vrts - push_back( osg::Vec3( 1.f , -1.f , 0.f ) ) ;
vrts - push_back( osg::Vec3( 1.f , 1.f , 0.f ) ) ;
vrts - push_back( osg::Vec3( -1.f , 1.f , 0.f ) ) ;
osg::ref_ptr osg::Vec4Array cols = new osg::Vec4Array() ;
geom - setColorArray( cols.get() ) ;
geom - setColorBinding( osg::Geometry::BIND_PER_VERTEX ) ;
cols - push_back( osg::Vec4( 1.f , 0.f , 0.f , 0.f ) ) ;
cols - push_back( osg::Vec4( 1.f , 1.f , 0.f , 1.f ) ) ;
cols - push_back( osg::Vec4( 0.f , 1.f , 0.f , 0.f ) ) ;
cols - push_back( osg::Vec4( 0.f , 0.f , 1.f , 0.f ) ) ;
osg::ref_ptr osg::Vec3Array nrms = new osg::Vec3Array() ;
geom - setNormalArray( nrms.get() ) ;
geom - setNormalBinding( osg::Geometry::BIND_OVERALL ) ;
nrms - push_back( osg::Vec3( 0.f , 0.f , -1.f ) ) ;
geom - addPrimitiveSet( new osg::DrawArrays(
osg::PrimitiveSet::QUADS , 0 , 4 ) ) ;
osg::StateSet * state = geom - getOrCreateStateSet() ;
state - setMode( GL_LIGHTING , osg::StateAttribute::OFF ) ;
return grpRoot.get() ;
}
class RotateCallback : public osg::NodeCallback
{
public :
RotateCallback() : _angle( 0.0 ) {}
virtual void operator()( osg::Node * node , osg::NodeVisitor *
nodeVisitor )
{
osg::MatrixTransform * transformLeft = dynamic_cast
osg::MatrixTransform * ( node ) ;
osg::Matrix matrixRotate , matrixTranslate ;
matrixTranslate.makeTranslate( -2.0 , 0.0 , 0.0 ) ;
matrixRotate.makeRotate( _angle, osg::Vec3( 0.0 , 0.0 , 1.0 ) )
;
transformLeft - setMatrix( matrixRotate * matrixTranslate )
;
_angle += 0.01 ;
traverse( node , nodeVisitor ) ;
}
protected :
double _angle ;
} ;
osg::Node * createScene()
{
osg::ref_ptr osg::Node plane = createSceneGraph() ;
plane - setDataVariance( osg::Object::STATIC ) ;
osg::ref_ptr osg::MatrixTransform transformLeft = new
osg::MatrixTransform ;
transformLeft - setName( "Left Plane DYNAMIC" ) ;
transformLeft - setDataVariance( osg::Object::DYNAMIC ) ;
transformLeft - setUpdateCallback( new RotateCallback ) ;
osg::Matrix matrixTranslate ;
matrixTranslate.makeTranslate( -2.0f , 0.0f , 0.0f ) ;
transformLeft - setMatrix( matrixTranslate ) ;
transformLeft - addChild( plane.get() ) ;
osg::ref_ptr osg::MatrixTransform transformRght = new
osg::MatrixTransform ;
transformRght - setName( "Right Plane STATIC" ) ;
transformRght - setDataVariance( osg::Object::STATIC ) ;
matrixTranslate.makeTranslate( 2.0f , 0.0f , 0.0f ) ;
transformRght - setMatrix( matrixTranslate ) ;
transformRght - addChild( plane.get() ) ;
osg::ref_ptr osg::Group grpRoot = new osg::Group ;
grpRoot - setName( "Root Node" ) ;
grpRoot - setInitialBound( osg::BoundingSphere( osg::Vec3( 0 , 0
, 6 ) , 4 ) ) ;
grpRoot - setDataVariance(
Re: [osg-users] Orienting a model (matrixtrans) toward a targetlocation?
I believe you need to Invert the result to see vaules you are expecting http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials/CameraControl From: osg-users-boun...@lists.openscenegraph.org on behalf of Kris Dale Sent: Fri 8/21/2009 2:00 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Orienting a model (matrixtrans) toward a targetlocation? Chris 'Xenon' Hanson wrote: Kris Dale wrote: I've stepped through the calculations the source goes through and that's all coming out the same as I get when I do it by hand, I just don't understand where those are coming from. Obviously the position vector is inverted (-100 instead of +) and for whatever reason it's not pointing at the target location... man.. so confused.. I wish I had paid better attention in linear. Hahaha. The only thing that crosses my mind is that makeLookAt is typically used to composed LookAt modelview matrices, not matrices for object positioning. Obviously the code must work and be right, since it's used in OSG's positioning code in several places. I'm wondering if this usage means there is some non-obvious requirements that make it unsuitable for use as an object LookAt? -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum Even if that were the case, looking at just the raw numbers and nothing else, it's still producing incorrect output isn't it? If I give it (0,0,100) for the eye position, shouldn't (0,0,100, 1) be the final row of the matrix rather than (0,0,-100, 1)? And what about the direction vertices? If osg::Matrix::makeLookAt doesn't work... it looks like I'm back to my original question of trying to figure out what the equations are to finding the correct vectors for x and z when I've already set the y vector to point at the the target position. Curse graphics and their reliance on linear algebra! Then again, it's better than calculus I suppose ;) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16581#16581 ___ 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] Orienting a model (matrixtrans) toward a target location?
Kris Dale wrote: Even if that were the case, looking at just the raw numbers and nothing else, it's still producing incorrect output isn't it? If I give it (0,0,100) for the eye position, shouldn't (0,0,100, 1) be the final row of the matrix rather than (0,0,-100, 1)? And what about the direction vertices? If osg::Matrix::makeLookAt doesn't work... it looks like I'm back to my original question of trying to figure out what the equations are to finding the correct vectors for x and z when I've already set the y vector to point at the the target position. Curse graphics and their reliance on linear algebra! Then again, it's better than calculus I suppose ;) Sorry, matrices are my bane, so I am not the one to help you. -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Orienting a model (matrixtrans) toward a target location?
Hi Kris,
On 21/08/09 8:00 PM, Kris Dale wrote:
If osg::Matrix::makeLookAt doesn't work... it looks like I'm back to my original
question of trying to figure out what the equations are to finding the correct
vectors
for x and z when I've already set the y vector to point at the the target
position.
makeLookAt should still be fine but it is pretty much geared for use with a view matrix.
The OpenGL camera looks down the negative Z-axis and gluLookAt and osg::Matrix::makeLookAt
produce matrices for that.
Why don't you try 'makeRotate(Vec3 from, Vec3 to)'? 'from' whould be your rockets
forward vector and 'to' would be the normalized ('target' - 'pos') vector.
You could combine that matrix with a translation to 'pos' or use 'getRotate' to obtain a
quaternion to put into a PositionAttitudeTransform.
Should work. (Famous last words, I know ;-)
Cheers,
/ulrich
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Orienting a model (matrixtrans) toward a target location?
[quote=Jason Daly]Kris Dale wrote: I just read the man page for gluLookAt, and I think I get the problem. Hopefully, I can describe the issue adequately :-) gluLookAt (and, by extension, osg::Matrix::makeLookAt), is designed to create a ModelView matrix with the given parameters. If you know how OpenGL works, you'll understand that a modelview matrix combines the modeling matrix (which places objects in the world) with the view matrix (which places the world with respect to the view). With this in mind, the resulting matrix makes perfect sense. Think of it this way, instead of moving the viewpoint to (0, 0, 100), you keep the view at the origin and move the world to (0, 0, -100). Does that help? To get what you're looking for, you might try inverting the result of makeLookAt (not sure if this is the answer, but it could be). --J -- Post generated by Mail2Forum That does actually help a bit. Running the matrix through invert didn't work but I'm slowly starting to get an understanding of might be required to achieve the result I'm looking for.. and it's a bit more than I originally anticipated. It turns out that I haven't entirely been asking the right questions, so it's been hard to get the right answers. In a way the answer is simple matrix math, though obviously enough as you've seen from me not THAT simple as it involves some linear algebra and I'm not a big fan... anywho, the thing I hadn't been considering is that not only do I have to come up with the y-vector (which I was using as the target vector), but as I realized from someone bringing up gluLookAt and it's osg relative, I need to know what my up-vector is going to be. Trying to go at this without an up-vector has been a major part of why I've been hitting such a deadlock. Earlier in this thread someone asked if the target was moving and I said that I would worry about animation later and that right now I was only worried about making the model face the target, and that I would worry about movement later. The idea was more that I would worry about animating the movement of the model from it's current orientation toward it's new target orientation later. The problem is, assuming the model can be positioned anywhere oriented in any direction in space, it occurs to me I think if I'm going to know what the up-vector for the model is going to be for the object at the time it points at the target-vector, I'm going to have to know it each step of the rotation toward it... And I hadn't considered how complicated this was going to be... ooo boy... Man this gets more complicated by the minute... -_- MY BRAIN HURTS (Monty Python reference anyone?) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16588#16588 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Orienting a model (matrixtrans) toward a target location?
Ulrich Hertlein wrote:
Hi Kris,
On 21/08/09 8:00 PM, Kris Dale wrote:
If osg::Matrix::makeLookAt doesn't work... it looks like I'm back to my
original
question of trying to figure out what the equations are to finding the
correct vectors
for x and z when I've already set the y vector to point at the the target
position.
makeLookAt should still be fine but it is pretty much geared for use with a
view matrix.
The OpenGL camera looks down the negative Z-axis and gluLookAt and
osg::Matrix::makeLookAt
produce matrices for that.
Why don't you try 'makeRotate(Vec3 from, Vec3 to)'? 'from' whould be your
rockets
forward vector and 'to' would be the normalized ('target' - 'pos') vector.
You could combine that matrix with a translation to 'pos' or use 'getRotate'
to obtain a
quaternion to put into a PositionAttitudeTransform.
Should work. (Famous last words, I know ;-)
Cheers,
/ulrich
___
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Post generated by Mail2Forum
Bahahahaha. Brilliant! The makeRotate(from, to) works like a champ! From
here I think it's just a matter of figuring out how to animate the effect (slow
turning toward the target location...) This is great though! I'm definitely
going to have to dive into the source and see how it goes about coming up with
this orientation because after spending a few days on this my brain is
absolutely about to catch FIRE about it. hahaha.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=16589#16589
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Orienting a model (matrixtrans) toward a targetlocation?
Kris Dale wrote on Friday, August 21, 2009 3:51 PM: Bahahahaha. Brilliant! The makeRotate(from, to) works like a champ! From here I think it's just a matter of figuring out how to animate the effect (slow turning toward the target location...) This is great though! I'm definitely going to have to dive into the source and see how it goes about coming up with this orientation because after spending a few days on this my brain is absolutely about to catch FIRE about it. hahaha. Matrix::getRotate() and Quat::slerp()? -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Porting Performer code to OpenSceneGraph
Hello All, We have a rather complex graphics application (about 100,000 lines of code) developed on Performer that we need to port to openscenegraph. What do you think, in the ballpark, the effort will be in man month for someone with mid level experience with openscenegraph and performer? The application worked on multipipes system (ie SGI's prism systems). One possible concern would be, a question on the architecture. Performer has a concept of separate APP and DRAW processes. In a multi-processing environment these are separate processes. And Performer takes care of multi-processing and multi-piping. How is this handled in openscenegraph? Another possible challenge is memory management. Performer puts everything into shared memory, where multiple processes can access stuff. Is this handled the same in openscenegraph? or this is handled transparently? There are both c and c++ interfaces to Performer. The software package we want to port uses the c interface, as one of the required external module is in C. I am assuming this will not be an issue? Thank you much Simon ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Plugins or Nodekits
I want to add some functionality to my app as a plugin - so the user can add features at runtime. It just needs to take a tree of nodes and some other data (possibly as an XML string) and do something to the nodes, or return a result xml string. Is there an example/tutorial of using OSGs plugin system for a non-file operation? Thanks. Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16592#16592 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Plugins or Nodekits
Hi Martin I want to add some functionality to my app as a plugin - so the user can add features at runtime. It just needs to take a tree of nodes and some other data (possibly as an XML string) and do something to the nodes, or return a result xml string. I cannot tell a tutorial on ogs plugins ( though the system is quite well developed ) but could offer two general tutorials which will allow you to develop your own general purpose plugin system first link begins with basics then ends up with template version second extends template idea even further. ( you may also add defines to different versions of you plugin system using LoadLibrary and linux dlopen see http://www.codeproject.com/KB/architecture/plat_ind_coding.aspx ) http://www.flipcode.com/archives/Adding_Plug-ins_To_Your_Application.shtml http://www.nuclex.org/articles/building-a-better-plugin-architecture Regards Sergey http://www.hmelyoff.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Plugins or Nodekits
Thanks I was hoping to avoid reinventing too many wheels. OSG already has code to find a plugin by name, create nodes, receive nodes. I just needed some examples of accessing a node directly through the registry, getting back changed nodes and passing/receiving extra data. Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16595#16595 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Porting Performer code to OpenSceneGraph
Simon Su wrote: Hello All, Hi, Simon, I remember you from the Performer list :-) We have a rather complex graphics application (about 100,000 lines of code) developed on Performer that we need to port to openscenegraph. What do you think, in the ballpark, the effort will be in man month for someone with mid level experience with openscenegraph and performer? The application worked on multipipes system (ie SGI's prism systems). I just finished a port of a moderately-sized Performer app (about 25k lines). It's not as large as yours, but it was fairly complex and it was old (from the IRIX/IrisGL/Performer 2.0 days), so that added a bit of complexity. It took me about three-four weeks. I'd rate my experience with both scene graphs as extensive, so it might take someone with mild experience a bit longer. In most cases, OSG maps to Performer pretty directly. There are differences, but they're usually not difficult to handle. Overall, I think OSG is more flexible than Performer. For example, you can put state anywhere in the scene, not just at the leaves. You might run into a case or two where Performer does something that OSG doesn't do. These are what can take the most time. pfEarthSky is the most obvious example of this. If you want a Performer-like earth/sky model, you'll have to use an external nodekit (like osgEphemeris), or you'll have to write it yourself. One other thing to consider is dealing with geometry. If your app uses pfGeoSets with indexed attribute lists, it would be a good idea to de-index the lists. Modern graphics cards don't handle indexed attribute lists very well (they'll run really slowly). You mentioned that you were using a Prism, though, so hopefully your app already uses pfGeoArrays, which don't use indexed attribute lists. One possible concern would be, a question on the architecture. Performer has a concept of separate APP and DRAW processes. In a multi-processing environment these are separate processes. And Performer takes care of multi-processing and multi-piping. How is this handled in openscenegraph? Instead of multiple processes, OSG uses multiple threads. There are several threading models to choose from (similar to Performer's options for splitting the processes, but not exactly the same). The threads are set up by whichever Viewer class you choose. The Viewer classes also help you deal with multiple displays. You'll either pick Viewer (a single viewpoint on a single scene, possibly with multiple cameras/displays slaved to the master viewpoint), or CompositeViewer (multiple viewpoints and/or multiple scenes). Another possible challenge is memory management. Performer puts everything into shared memory, where multiple processes can access stuff. Is this handled the same in openscenegraph? or this is handled transparently? As mentioned above, OSG uses threads instead of processes. Typically with Performer, you'll have a per-channel shared memory structure that you pass with pfPassChanData() or whatever. When you port, you can still use that structure to keep it simple. You don't need to call anything special to share it because your memory space is already shared between threads. You might need to protect it with a mutex, though, depending on how you use or access the data. There are both c and c++ interfaces to Performer. The software package we want to port uses the c interface, as one of the required external module is in C. I am assuming this will not be an issue? I'm not sure what you're asking here. OSG is C++ only, so you'll have to port the C Performer code to C++ OSG code. Hope this helps. If you have any more questions, let me know. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
