Re: [osg-users] collada plugin problems
Thanks Farshid, It looks like it's a bug in the latest version of FeelingSoftware's Max exporter, I've sent them a bug report. In larger collada exports some of the alpha components are becoming NaN's as well. -Drew Farshid Lashkari wrote: Hi Drew, On 10/10/06, Drew Whitehouse <[EMAIL PROTECTED]> wrote: Can someone knowledgeable take a look at this collada file and it's .osg equivalent and tell me why nothing is showing up in osgviewer ? It looks like it should, and osgviewer is reporting the existence of 800+ primitives. The .dae file is being exported from 3DSMax, and converted using osgconv/OSG1.2. The material's alpha is set to 0 in the osg file, so it is 100% transparent. Change the alpha values to 1 and it should show up fine. It worked here. -Farshid ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] collada plugin problems
Hi Drew, On 10/10/06, Drew Whitehouse <[EMAIL PROTECTED]> wrote: Can someone knowledgeable take a look at this collada file and it's .osg equivalent and tell me why nothing is showing up in osgviewer ? It looks like it should, and osgviewer is reporting the existence of 800+ primitives. The .dae file is being exported from 3DSMax, and converted using osgconv/OSG1.2. The material's alpha is set to 0 in the osg file, so it is 100% transparent. Change the alpha values to 1 and it should show up fine. It worked here. -Farshid ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] collada plugin problems
Hi all, Can someone knowledgeable take a look at this collada file and it's .osg equivalent and tell me why nothing is showing up in osgviewer ? It looks like it should, and osgviewer is reporting the existence of 800+ primitives. The .dae file is being exported from 3DSMax, and converted using osgconv/OSG1.2. http://anusf.anu.edu.au/~drw900/osg/test.dae http://anusf.anu.edu.au/~drw900/osg/test.osg Thanks, Drew ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] wxwidgets
Hi Antoine, Due to changes in osgGA since 1.0 you’ll find that the mVue example is a little out of date now. However, the general concepts of how mVue was put together still apply. I have some simple code in a VS7.1 project integrating wxWidgets and OSG that I was using to debug a recent issue with NVidia drivers that may be of use. If you like I will tidy it up and put it on the wiki tonight/tomorrow for others starting out with wx and osg. Gian Hello, I am trying to use OSG into a GUI made on WxWidgets under VC++8.0 but I cannot find much information about linking OSG to 3rd parties GUI libraries. I found the namespace osgGA which I believe provides the functions I need, but the doc about it is not really intended to be used by a green in OSG like I am. I also had a look at a project called mVue which exactly did what I want (and much more), unfortunately the project is already rather big, so I get lost in all the code (though I spent some time on it…). And last I had a look at the examples (of course), but they use osgProducer, so all the work is already done, and as it is rather complete, well I have the same problem as before: I get lost… If anybody had any simpler information about it, or a small project with the minimal requirements, that would be tremendous! Thanks, Antoine. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Fedora Core 4 packages -- OSG 1.2
Hi Eric, You can ftp them to openscenegraph.net/upload. Use your email address as the password. Send me an email when they are up and I'll add something to the binary download page. -donOn 10/10/06, Eric Sokolowsky <[EMAIL PROTECTED]> wrote: I have created some packages of OSG-1.2 for Fedora Core 4. Where shouldI upload these? They're kind of big for an email attachment, but I supposeI could send them to the submissions list.-- __ Eric Sokolowsky (GST)NASA Goddard Space Flight Center/ __/__/_/__ Visualization ProgrammerScientific Visualization Studio / __/ _/ / _/ 301.286.3751 Mailstop 610.3 Bldg 28 Rm E102 /___/_//_/__/ [EMAIL PROTECTED] Greenbelt, MD 20771___osg-users mailing list osg-users@openscenegraph.nethttp://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] wxwidgets
Hello, I am trying to use OSG into a GUI made on WxWidgets under VC++8.0 but I cannot find much information about linking OSG to 3rd parties GUI libraries. I found the namespace osgGA which I believe provides the functions I need, but the doc about it is not really intended to be used by a green in OSG like I am. I also had a look at a project called mVue which exactly did what I want (and much more), unfortunately the project is already rather big, so I get lost in all the code (though I spent some time on it…). And last I had a look at the examples (of course), but they use osgProducer, so all the work is already done, and as it is rather complete, well I have the same problem as before: I get lost… If anybody had any simpler information about it, or a small project with the minimal requirements, that would be tremendous! Thanks, Antoine. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Image processing question
Hi Serge, Two image processing libraries worth a look are DevIL and ImageMagick. The latter is pretty hefty, but has a lot of functionality. DevIL - http://openil.sourceforge.net/ ImageMagick - http://www.imagemagick.org/script/index.php Good luck, Gian > -Original Message- > From: [EMAIL PROTECTED] [mailto:osg-users- > [EMAIL PROTECTED] On Behalf Of Serge Lages > Sent: Wednesday, 11 October 2006 3:22 AM > To: osg users > Subject: [osg-users] Image processing question > > Hi all, > > I am looking for an image processing library to use with OSG, I've tried : > http://cimg.sourceforge.net/ > But I can't manage to get good result with it (scaling an image result > on a corrupted buffer :/). > Anyone have tried it ? > > Or anyone knows another good image processing library ? Which allows > me to process large buffers. For exemple I would like to scale just a > part of an image directly without copying this part into another > buffer before scaling it. > > Thanks in advance ! > > -- > Serge Lages > http://www.magrathea-engine.org > ___ > osg-users mailing list > osg-users@openscenegraph.net > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Semi-OT: Plugin architectures
Hi Chris,
I used my own version of COM rather than the Microsoft version because of
lack of understanding and because I foresaw issues with timing (never proved
or disproved).
The skeleton of my simplified version is attached together with a skeleton
app method. There are things that could be improved, but I was following a
Microsoft code example (from VS5) and bear in mind that the interface was
supposed be compatible with both C and C++. I used the same names as the
Microsoft version, except for a prefix. To use the interface it is not
necessary to add the "Example.lib" to your build system if you use the
LoadLibrary call, and all you need to publish is the .h file and the DLL.
The Microsoft version may be prettier, but I have source code to my version!
Microsoft have several macros to dress up their COM interface, but I just
elected not to implement my cutdown version entirely their way.
It took me several days to realise that COM is really simple, so I hope my
example helps you trim a few corners off your learning experience.
Regards
PS. I have not compiled the example and have no interest in maintaining it.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Chris Hanson
Sent: 10 October 2006 18:45
To: osg users
Subject: Re: [osg-users] Semi-OT: Plugin architectures
Philip Taylor wrote:
>"COM/ActiveX is out for many reasons."
> Why? My undertanding is that the basis of COM is a C structure, I would
have
> thought it met your design requirement. I have implemented a couple of
> components where the structure was more a C++ rather C style structure.
I am somewhat familiar with COM, having tried to come to grips with it
before. COM
seems unsuitable for several reasons:
Totally Windows dependent. I've seen Mozilla's XPCOM, but it seems really
complicated
to understand and build and use outside Mozilla.
Really requires people to be into the "COM mindset". It's not just like
writing some
simple code -- only the code can be dynamically added to an application. You
really have
to grasp COM's whole philosophy to get going with it.
My understanding of COM is that it requires objects to register
themselves with the
Windows registry before being accessible, and I think this is an
abomination. I understand
their reasons for it, but there are reasons I don't want my app polluting
the user's
system in that fashion. I also need something that can basically run right
out of the box
as an EXE without needing installation/uninstallation.
I'm also not trying to implement RPC and inter-endian mixing, so COM's
marshalling and
such are overkill.
I'm thinking I may just do something myself, since I haven't found an
existing solution
the meets enough of my criteria. I'll probably adopt some of the low-level
principles COM
uses to make itself language-independent and such.
> The advantage of COM is runtime linking - no need to distribute lib
files -
> just an include file to describe the interfaces returned by the factory
> method and the actual DLL.
I'm looking at doing something similar, with late-binding using method
name strings as
opposed to IDL files and GUIDs and such.
> Alternatively look at how OSG handles its plugins.
As I mentioned above, OSG's plugin design is suitable for OSG, but pretty
much lacks
many of the important criteria I'm looking for. Think of how 3dsMax breaks
plugin
compatibility everytime they release a new version, versus Photoshop which
can run plugins
written in the 3.0 era.
--
Chris 'Xenon' Hanson aka Eric Hammil | http://www.3DNature.com/ eric at
logrus
"I set the wheels in motion, turn up all the machines, activate the
programs,
and run behind the scenes. I set the clouds in motion, turn up light and
sound,
activate the window, and watch the world go 'round." -Prime Mover, Rush.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
//*
// FILE HEADER
// ~~
// File Name: com_example.cpp
//
// Project ID : ---/---
//
// Originated : Oct 2006 Philip Taylor
//
// Description : Implementation of an example COM style interface.
//
//**
#include "stdafx.h"
#include "com_example.h"
#ifdef _DEBUG
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
// **
// CLASS HEADER
// ~ ~~
// Name : CExampleFactory
//
// Description : A derived DLL interface to the component factory.
//
// **
class CExampleFactory : public CExampleFactory_API
{
public :
unsigned int m_dwRef;
public :
voidQueryInt
[osg-users] Fedora Core 4 packages -- OSG 1.2
I have created some packages of OSG-1.2 for Fedora Core 4. Where should I upload these? They're kind of big for an email attachment, but I suppose I could send them to the submissions list. -- __ Eric Sokolowsky (GST)NASA Goddard Space Flight Center / __/__/_/__ Visualization ProgrammerScientific Visualization Studio / __/ _/ / _/ 301.286.3751 Mailstop 610.3 Bldg 28 Rm E102 /___/_//_/__/ [EMAIL PROTECTED] Greenbelt, MD 20771 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Tga-texture without background on quad not visible in scene
At 16:46 10/10/2006, you wrote:
hi all,
i have a geode with a geometry-node in my scene which has attached
an osg::PrimitiveSet::QUADS.
i put a tga-texture on that quad using a osg::stateset. if i use a
tga-texture with a background i can see the whole quad in my scene (a square).
but then i wanted to change the texture to a texture without a
background (alpha-blending?!) i did this but now i cant see my quad
in the scene anymore even though i checked - it exists. what is
wrong? how is it possible to put a texture on a quad which does has
a background so i just a the actual shape of the content of the
image not the quad shape...
here is what i did:
// specify texture
dtCore::RefPtr shoeTex = new osg::Texture2D;
// protect from being optimized away as static state:
shoeTex->setDataVariance(osg::Object::DYNAMIC);
// load an image by reading a file:
dtCore::RefPtr shoeImg = osgDB::readImageFile( texName );
if (!shoeImg.get())
{
std::cout << " couldn't find texture, quiting." << std::endl;
}
// Assign the texture to the image we read from file:
shoeTex->setImage(shoeImg.get());
// Create a new StateSet with default settings:
dtCore::RefPtr stateOne = new osg::StateSet();
stateOne->setMode( GL_BLEND, osg::StateAttribute::ON );
// Assign texture unit 0 of our new StateSet to the texture
// enable the texture.
stateOne->setTextureAttributeAndModes(0, shoeTex.get(),
osg::StateAttribute::ON);
geode->setStateSet(stateOne.get());
thanks in advance.
_
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=0066
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
[osg-users] Tga-texture without background on quad not visible in scene
hi all,
i have a geode with a geometry-node in my scene which has attached an
osg::PrimitiveSet::QUADS.
i put a tga-texture on that quad using a osg::stateset. if i use a tga-texture
with a background i can see the whole quad in my scene (a square).
but then i wanted to change the texture to a texture without a background
(alpha-blending?!) i did this but now i cant see my quad in the scene anymore
even though i checked - it exists. what is wrong? how is it possible to put a
texture on a quad which does has a background so i just a the actual shape of
the content of the image not the quad shape...
here is what i did:
// specify texture
dtCore::RefPtr shoeTex = new osg::Texture2D;
// protect from being optimized away as static state:
shoeTex->setDataVariance(osg::Object::DYNAMIC);
// load an image by reading a file:
dtCore::RefPtr shoeImg = osgDB::readImageFile( texName );
if (!shoeImg.get())
{
std::cout << " couldn't find texture, quiting." << std::endl;
}
// Assign the texture to the image we read from file:
shoeTex->setImage(shoeImg.get());
// Create a new StateSet with default settings:
dtCore::RefPtr stateOne = new osg::StateSet();
stateOne->setMode( GL_BLEND, osg::StateAttribute::ON );
// Assign texture unit 0 of our new StateSet to the texture
// enable the texture.
stateOne->setTextureAttributeAndModes(0, shoeTex.get(),
osg::StateAttribute::ON);
geode->setStateSet(stateOne.get());
thanks in advance.
_
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=0066
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Semi-OT: Plugin architectures
I actually needed something like what you are describing here, a way of linking in external libraries in runtime a while back...What we ended up with was a plugin structure for lua.Its not optimal but it works well. We have a main executable that really doesnt know much about the world, but it has a lua-state and it knows how to "load a plugin and register it to lua".
So what we can do is take for example a class:class MyApp MyApp(); void run(); // starts my app and do whatever void doOtherthings() bool shutTheWholeThingDown() ...}write a LuaPlugin class:
LuaMyApp : public LuaPlugin{ virtual void init(); // will be called during loading}Run MyApp class through tolua++ and generate interface binder code, call that from LuaPlugin::init() which registrates the MyApp class into lua.
This results in a .dll/.so luaplugin_myapp.dllSo by starting the main app:DOS> main_app myapp.lua with a lua-file that specifies:myapp.lua:--requestPlugin("myapp")
myapp = MyApp:new()
myapp = MyApp:run()So its up to the author of the LuaMainApp plugin if he want to export all of the interface to lua or just the kick-off code.main_app doesnt know anything about MyApp.
There are of course a few Singletons to enable access to a scenegraph and some other things.All this said, I would love to see a slick API/toolset that makes it possible to get COM:ish functionality, while still portable and with a small overhead mainly in use!
/AndersOn 10/10/06, Dmitry Baikov <[EMAIL PROTECTED]> wrote:
Chris Hanson wrote:> As I mentioned above, OSG's plugin design is suitable for OSG, but> pretty much lacks many of the important criteria I'm looking for.> Think of how 3dsMax breaks plugin compatibility everytime they release
> a new version, versus Photoshop which can run plugins written in the> 3.0 era.>It all depends on the complexity of data structures that will bemanupulated and/or passed between plugins.On possible solution is to use some scripting language with good
C-interface as a glue and write all plugins as language-modules.For us Lua (http://www.lua.org) is sufficient. Many projects use Python(as being more powerful, but complex).
Dmitry.___osg-users mailing listosg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-usershttp://www.openscenegraph.org/--
Anders Backman Email:[EMAIL PROTECTED] HPC2N/VRlab Phone:+46 (0)90-786 9936 Umea university Cellular: +46 (0)70-392 64 67
S-901 87 UMEA SWEDEN Fax: +46 90-786 6126 http://www.cs.umu.se/~andersb
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Starfield
On 10/10/06, Ivan Bolčina <[EMAIL PROTECTED]> wrote: Hi. How do you suggest that I implements star field effect, like traveling through hyperspace? I would do this with a buntch of pixels. How to make them resolution independent? Which classes to use? Look at the osgspacewarp exemple, we are using it to make this effect on our application. -- Serge Lages http://www.magrathea-engine.org ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Semi-OT: Plugin architectures
Chris Hanson wrote: As I mentioned above, OSG's plugin design is suitable for OSG, but pretty much lacks many of the important criteria I'm looking for. Think of how 3dsMax breaks plugin compatibility everytime they release a new version, versus Photoshop which can run plugins written in the 3.0 era. It all depends on the complexity of data structures that will be manupulated and/or passed between plugins. On possible solution is to use some scripting language with good C-interface as a glue and write all plugins as language-modules. For us Lua (http://www.lua.org) is sufficient. Many projects use Python (as being more powerful, but complex). Dmitry. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OSG and clustering
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Don Burns wrote: > Thanks, Anders, I forgot about osgVR . > > But to answer: > > who needs clustering? >> > > Those who want more than 8 display devices. :) > > -don > Also those who are hitting a fill-rate limit with less than 8 - remember that PCI-E shares the bandwidth between the cards. E.g. my 16x PCI-E drops to 8x with two cards installed, on the quad SLI machines it goes down to 4x. That has a significant performance impact. On the old Onyx this wasn't an issue - the interconnects between the video pipes and the CPUs were dedicated, there was not only a single bus shared by all video hw and the CPUs as on a PC. Regards, Jan - -- Jan Ciger GPG public key: http://www.keyserver.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFFK+F3n11XseNj94gRAr8gAKDFC7fjEglm9y2LR2vEbn/2xPcixQCeOaSN /qyvsXjeNp4GQBPw9cUdCMk= =FNWf -END PGP SIGNATURE- ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OSG and clustering
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Anders Backman wrote: > Its called osgVR > > http://www.nbi.dk/~gronager/osgVR.html > > Now I know that Michael hasn't updated the code for a while, but this > should > certainly work as a good starting point on what you want Jan. Thanks for the pointer, it looks good. I will have a look at it - it may be actually enough for what we need. > I use to have the same issues when we were discussing the clustering of > some > of our applications. > The problem in our apps were that the scenegraph itself was very dynamic > both in terms of adding/removing nodes but also in change of > transformations > for many objects, interaction (events) etc... > > So I felt a slight burden on explicitly "cluster" such an application, in > comparison of writing one app, and just specifying where the renderingnodes > were. This is also my feeling. Even though the scene graph will probably not have nodes added and removed on the fly, there will be plenty of position updates and such. Cluster is not really an optimal architecture for such application, but you have to work with what you have. > OpenSG has implemented clustering on a broad level. The whole scenegraph is > designed for parallellism. That was an early decision from them. That also > had a large impact on the usability and the complexity of the code, > whenever > a part of the scene is changed it is copied and the copies has to be > syncronized, a lot of work. That's exactly why I would prefer to use OSG than to port your Replicant code or osgCal to OpenSG in order to be able to do character animation we need. I am not fancying having to deal with some heavy access synchronization code. > I said in the beginning we had some issues with the thought of having to do > explicit clustering, but now with Quad DualCore, multiGPU machines, who > needs clustering? > > I told myself in the beginning of 2001, dont do clustering, just wait for > the next generation onyx, and now they are here! > For a small sub-fraction of the price :-) Well, most multi-gpu machines can host at most two PCI-E cards (these sold as SLI-ready). That means at most 4 video outputs. A CAVE still needs 6 + a console. You could do that with the quad-sli mainboards, but these systems are rare and hugely expensive. Not to mention cooling and general stability issues. I think that the clusters are here to stay for the foreseeable future. Agreed, Onyx was by far the best solution for this - put as many pipes in as you want (up to 8 was the limit?), 128 CPUs should be more than enough and the geek factor is hard to beat :) Unfortunately it also blew one's budget several times over :(( We used to pay over 75000 Swiss franks annual maintenance for a small one - just two pipes and 6 CPUs. For that money you can build one hell of a cluster already. Regards, Jan - -- Jan Ciger GPG public key: http://www.keyserver.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFFK+A1n11XseNj94gRAq4mAJ97S/ZprbkQiZoQE1O83Y/BecHJFgCg4P4/ 4leKwOzzI71GFt2tvAaXGTw= =7oqY -END PGP SIGNATURE- ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Starfield
Hi. How do you suggest that I implements star field effect, like traveling through hyperspace? I would do this with a buntch of pixels. How to make them resolution independent? Which classes to use? ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OSG and clustering
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Don Burns wrote: >> I'm afraid I cut my teeth on low level network programming and most tools >> feel like overkill for this kind of application. <..snip..> > >> UDP (DATAGRAM) packets can send up to a configurable (and queriable) amount >> of data per packet. (I think the default is around 1540 bytes, or >> something >> like that). In the simple case, your data can fit into one packet, which >> can be sent every frame (about 12 double matricies, or 24 single precision >> matrices). >> Anyway, for me, this is such low hanging fruit that I just do the simple >> (some times adhoc) method. In fact, a solution could have been written in >> about the time it takes to write this email thread. I agree, I have no issues with writing low-level code like that (and have done so many times) however this sort of solution has two problems: - - It is difficult to get all the nasty corner cases right (packet defragmentation, dropped connections, retransmits, etc.) - - It is difficult to "sell" it to people used to big buzzwords and huge frameworks - believe me or not - we had to build a simulator which was passing huge chunks of XML around for hundreds of simulated humans just to update their positions - an "enterprise" solution, indeed. You could probably imagine the performance - 90% of time was spent parsing XML. That's why I was asking whether there are some commonly used libraries for this - both to ease the pain of the low-level coding and to make it more digestible for the others involved. >> This actually becomes a hardware video sync problem. It really is a >> different level of synchronization than the data sync. I cover some of >> that >> in this article: > >> http://www.donburns.net/OSG/Articles/Synchronization/ Nice summary, thanks for the link. >> What I don't cover in the article is the issue of stereo. In an active >> stereo system, I believe the issue is one of synchronizing drawing to the >> first buffer (left back, or right back) with data. That is, the data need >> only update once for every two "subframes" of stereo. That makes sense - you push one data frame out, render two frames (left and right) and then push (and synchronize) another data frame out. Thanks for the information, I have to check how they are actually driving the CAVE at the moment and then we make a decision how to proceed with this. Regards, Jan - -- Jan Ciger GPG public key: http://www.keyserver.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFFK9x3n11XseNj94gRAiaLAJ4wab4K317OGBdhQVFh2wUNdNzqkACfa/3b hezOVTdtIEwjePCYZfIJzVg= =dEvg -END PGP SIGNATURE- ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Semi-OT: Plugin architectures
Philip Taylor wrote: "COM/ActiveX is out for many reasons." Why? My undertanding is that the basis of COM is a C structure, I would have thought it met your design requirement. I have implemented a couple of components where the structure was more a C++ rather C style structure. I am somewhat familiar with COM, having tried to come to grips with it before. COM seems unsuitable for several reasons: Totally Windows dependent. I've seen Mozilla's XPCOM, but it seems really complicated to understand and build and use outside Mozilla. Really requires people to be into the "COM mindset". It's not just like writing some simple code -- only the code can be dynamically added to an application. You really have to grasp COM's whole philosophy to get going with it. My understanding of COM is that it requires objects to register themselves with the Windows registry before being accessible, and I think this is an abomination. I understand their reasons for it, but there are reasons I don't want my app polluting the user's system in that fashion. I also need something that can basically run right out of the box as an EXE without needing installation/uninstallation. I'm also not trying to implement RPC and inter-endian mixing, so COM's marshalling and such are overkill. I'm thinking I may just do something myself, since I haven't found an existing solution the meets enough of my criteria. I'll probably adopt some of the low-level principles COM uses to make itself language-independent and such. The advantage of COM is runtime linking - no need to distribute lib files - just an include file to describe the interfaces returned by the factory method and the actual DLL. I'm looking at doing something similar, with late-binding using method name strings as opposed to IDL files and GUIDs and such. Alternatively look at how OSG handles its plugins. As I mentioned above, OSG's plugin design is suitable for OSG, but pretty much lacks many of the important criteria I'm looking for. Think of how 3dsMax breaks plugin compatibility everytime they release a new version, versus Photoshop which can run plugins written in the 3.0 era. -- Chris 'Xenon' Hanson aka Eric Hammil | http://www.3DNature.com/ eric at logrus "I set the wheels in motion, turn up all the machines, activate the programs, and run behind the scenes. I set the clouds in motion, turn up light and sound, activate the window, and watch the world go 'round." -Prime Mover, Rush. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Image processing question
Hi all, I am looking for an image processing library to use with OSG, I've tried : http://cimg.sourceforge.net/ But I can't manage to get good result with it (scaling an image result on a corrupted buffer :/). Anyone have tried it ? Or anyone knows another good image processing library ? Which allows me to process large buffers. For exemple I would like to scale just a part of an image directly without copying this part into another buffer before scaling it. Thanks in advance ! -- Serge Lages http://www.magrathea-engine.org ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OSG and clustering
Thanks, Anders, I forgot about osgVR . But to answer: who needs clustering? Those who want more than 8 display devices. :) -donOn 10/10/06, Anders Backman <[EMAIL PROTECTED]> wrote: There is actually an cluster implementation of osg, im not sure if its updated lately, but its using MPI for communication. and I know it distributes changes in the scenegraph, such as transforms, materials transparently... Its called osgVR http://www.nbi.dk/~gronager/osgVR.html Now I know that Michael hasn't updated the code for a while, but this should certainly work as a good starting point on what you want Jan. I use to have the same issues when we were discussing the clustering of some of our applications. The problem in our apps were that the scenegraph itself was very dynamic both in terms of adding/removing nodes but also in change of transformations for many objects, interaction (events) etc... So I felt a slight burden on explicitly "cluster" such an application, in comparison of writing one app, and just specifying where the renderingnodes were. OpenSG has implemented clustering on a broad level. The whole scenegraph is designed for parallellism. That was an early decision from them. That also had a large impact on the usability and the complexity of the code, whenever a part of the scene is changed it is copied and the copies has to be syncronized, a lot of work. But they had particle examples running on dozens of machines with 20.000 particles all updated on one machine and reflected without any explicit distributioncode in the app... I said in the beginning we had some issues with the thought of having to do explicit clustering, but now with Quad DualCore, multiGPU machines, who needs clustering? I told myself in the beginning of 2001, dont do clustering, just wait for the next generation onyx, and now they are here! For a small sub-fraction of the price :-) /Anders On 10/10/06, Don Burns <[EMAIL PROTECTED] > wrote: Hi Jan,On 10/9/06, Jan Ciger < [EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE-Hash: SHA1Hello,Don Burns wrote:> The luxury we have with many graphics clusters is that we can impose a> master/slave architecture, where the slaves are simply readers. Only the > master writes to shared buffers, and the slaves simply receive the updates> at frame synchronization time.This is pretty much what I had in mind. The rendering slaves do not needto update the scene graph themselves, so it is a one-way affair simplifying the synchronization process quite a bit.> I think what you've described is a simple master-writer/slave-reader> architecture.Yes, I think that would be most appropriate for this case. > To make a humvee move, for> example, you call>>matrixTransform->setMatrix(matrix);>> where matrixTransform is the node that moves the vehicle and matrix is> where > the data containing the vehicle's position and attitude is stored for this> frame. In this case, 'matrix' can be allocated in the cluster's shared> memory pool (shared between nodes), but matrixTransform does not need to > be.This was what I was thinking about when I wrote about the ad-hocsolution. Is there a toolkit able to do this? (synchronize some sort ofnetwork shared memory). I guess that this is what VR Juggler does and I could probably find some more online as well. Probably even MPI coulddo. Do you have some preferred tool to do this sort of work? I'm afraid I cut my teeth on low level network programming and most tools feel like overkill for this kind of application. The osgcluster example was written by an example I gave Robert a while back and is very simple. In this case, it sends nothing more than the eyepoint. But how much data you send is just a matter of data size. UDP (DATAGRAM) packets can send up to a configurable (and queriable) amount of data per packet. (I think the default is around 1540 bytes, or something like that). In the simple case, your data can fit into one packet, which can be sent every frame (about 12 double matricies, or 24 single precision matrices). Anyway, for me, this is such low hanging fruit that I just do the simple (some times adhoc) method. In fact, a solution could have been written in about the time it takes to write this email thread. > Further, a simple update callback on matrixTransform can effect an > automatic update of the vehicle's position. You need only , then, > synchronize the shared buffers before calling the update traversal.Ah, neat. I didn't think about using the update callback to do this. Nice.> At the top level of the application then, running on the master, simply > updates the position of the vehicles, etc. synchronizes the shared buffers> and the positions are updated in graphics about a frame and a half later.>What about active stereo? Wouldn't this delay cause problems? AFAIK, for active stereo the rendering nodes have to be synchronizedframe-by-frame, otherwise the stereo falls apart at the edges of thewalls of the CAVE. This actual
Re: [osg-users] OT : Rendering to memory with Mesa
THanks, JP, I'll look into this. -donOn 10/9/06, J.P. Delport <[EMAIL PROTECTED]> wrote: Hi,we're using an OSMesa32 (Offscreen Mesa with a floating point framebuffer in host memory) context coupled to SceneView. All rendering isdone in software and can be debugged/looked at with gdb.regards jpDon Burns wrote:> Has anyone had experience doing a fully software based renderer using> Mesa or other, even OpenGLSI?>> I'm currently doing something interesting with Pbuffers, but the future > of pbuffers is tenuous and still requires some crowbaring to get things> to work with an Xserver in login mode. A memory based frame buffer> would be a good alternative.>> -don> >> >> ___> osg-users mailing list> osg-users@openscenegraph.net> http://openscenegraph.net/mailman/listinfo/osg-users> http://www.openscenegraph.org/ --This message is subject to the CSIR's copyright, terms and conditions ande-mail legal notice. Views expressed herein do not necessarily represent theviews of the CSIR.CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.htmlCSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.htmlFor electronic copies of the CSIR Copyright, Terms and Conditions and the CSIRLegal Notice send a blank message with REQUEST LEGAL in the subject line to [EMAIL PROTECTED].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 listosg-users@openscenegraph.nethttp://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OSG and clustering
On 10/10/06, Anders Backman <[EMAIL PROTECTED]> wrote: I said in the beginning we had some issues with the thought of having to do explicit clustering, but now with Quad DualCore, multiGPU machines, who needs clustering? Who doesn't have it? ;-) ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Plumbing problems...
The false reporting of memory leaks is a known issue with the Visual Studio debugging environment, and has been discussed on this list many times, as new OSG users discover the error messages. From a previous post pulled randomly from the OSG list archive: >RE: [osg-news] Large numbers of memory leaks and huge STL overhead > >* This message: [ Message body ] [ More options ] >* Related messages: [ Next message ] [ Previous message ] [ Next in thread ] [ Replies ] > >From: S S E L >Date: Mon Jun 30 2003 - 00:54:10 PDT > >If you trace through the final moments of execution of an OSG program, >you'll discover that the VC++ memory logging occurs prior to any dlls being >unloaded. Objects that are declared static within a dll are destroyed when >the dll is unloaded. However, since this unloading occurs after the memory >check, then objects that have been declared static appear not to be deleted. >For example the osgDB::registry can appear to leak memory in a number of >places. However, if you place a breakpoint in the registry destructor it >does get called and memory allocated is indeed freed as you can readily >trace through the deletion of all of its members. > >Joseph Steel So, don't worry about them. The OSG libraries are about as clean as you will find anywhere. Blake Williams DRS TCS, Inc 651 Anchors Street Fort Walton Beach, FL 32548 (850) 302-3281Fax: (850) 302-3968 Notice: This is an unofficial communication and is not binding on DRS TCS, Inc. The only authorized representative of DRS TCS, Inc is the Contracts Department. This communication may contain privileged or other DRS TCS, Inc proprietary information. If you are not intended recipient or believe that you have received this communication in error, please reply to the sender indicating that fact and delete the copy you received. In addition, you should not print, retransmit, disseminate, or otherwise use the information. THANK YOU -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, October 10, 2006 6:07 AM To: osg-users@openscenegraph.net Subject: [osg-users] Plumbing problems... Hi Thibault, Thanks for the response, but I confess to being still a little confused. I have debug builds of my ActiveX control, and Debug builds of the OSG libraries. I know the allocation number of a memory block that is leaking, but this is within the OSG world. Do I therefore have to put the CRTAllocbreak (?) command in the OSG libraries ? I suppose I could go to this extreme, however I suppose what I'm looking for is a more general overview of how OSG shuts down. The OSG libraries define a lot of constant strings, and these are certainly being leaked when I'm shutting down my ActiveX control. It also looks as if the Cameras are hanging around too. Evidently I'm OSG is not shutting down properly, and I suppose I was looking for pointers as to how this might be occuring. I'm setting my viewer to NULL after syncing, and the control is being deleted, yet its almost as if the OSG reference structures aren't having their count decremented and then being destroyed. Help! Neil. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Plumbing problems...
Hi Thibault, Thanks for the response, but I confess to being still a little confused. I have debug builds of my ActiveX control, and Debug builds of the OSG libraries. I know the allocation number of a memory block that is leaking, but this is within the OSG world. Do I therefore have to put the CRTAllocbreak (?) command in the OSG libraries ? I suppose I could go to this extreme, however I suppose what I'm looking for is a more general overview of how OSG shuts down. The OSG libraries define a lot of constant strings, and these are certainly being leaked when I'm shutting down my ActiveX control. It also looks as if the Cameras are hanging around too. Evidently I'm OSG is not shutting down properly, and I suppose I was looking for pointers as to how this might be occuring. I'm setting my viewer to NULL after syncing, and the control is being deleted, yet its almost as if the OSG reference structures aren't having their count decremented and then being destroyed. Help! Neil. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OSG crash when calling getEnv() caused by OpenThreads bug in Win32 implementation?
HiOn 10/10/06, Kallfass, Daniel, SDGE1 <[EMAIL PROTECTED]> wrote: Hello,due to crashes that occur in OSG calling the getEnv() c-function inour multithreaded application, I tried to figure out what could bewrong.I noticed that the OpenThreads implementation for Win32 is using the Windows API function "CreateThread". But this function must not be usedin conjunction with the c-runtime. The function "_beginthreadex" shouldbe used instead. http://msdn.microsoft.com/library/default.asp?url="">html/_core_Library_Support_for_Multithreading.asphttp://www.microsoft.com/msj/0799/win32/win320799.aspx After carefully reading both articles, I still have some interrogations: does not the issue of using CreateThread instead of _createthreadex only applies when linking against LIBCMT ? The OSG/OP/OT is using MSVCRT (aka "Multithreaded runtime DLL" in Visual Studio) so the second point of the second paragraph of the second article (following me ?:) could apply ... which could be summarized as "use CreateThread". This is what ( i.e. the current OT) I've been doing for years without a hitch; but as I very rarely call the c-runtime, I might have simply never encountered your situation.But:- "In Redmond, do as Microsoft do" used to say my grandma - http://www.microsoft.com/msj/1099/win32/win321099.aspx insists on _beginthreadex being more robustSo I think you are right: we should switch to _beginthreadex and _endthreadex because even if it does not solve your bug, it is a cleaner practice. Snip: "There is absolutely no disadvantage to calling _beginthreadex, and your code is much safer. Besides, there are several advantages: compile-time checking if you link to an improper C runtime library; guaranteed freeing of the _tiddata block regardless of whether you're creating an EXE or a DLL and regardless of which multithreaded C runtime library you're using; signal support; and floating point exception support"Thibault ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] OSG crash when calling getEnv() caused by OpenThreads bug in Win32 implementation?
Hello, due to crashes that occur in OSG calling the getEnv() c-function in our multithreaded application, I tried to figure out what could be wrong. I noticed that the OpenThreads implementation for Win32 is using the Windows API function "CreateThread". But this function must not be used in conjunction with the c-runtime. The function "_beginthreadex" should be used instead. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/ html/_core_Library_Support_for_Multithreading.asp http://www.microsoft.com/msj/0799/win32/win320799.aspx This might explain the crash I had with OSG calling getEnv(). I haven't tried the fix yet, because I first wanted to ask the OSG community, if someone had similar problems with OSG and the c-runtime under windows. Thanks! Daniel Kallfass ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OSG and clustering
There is actually an cluster implementation of osg, im not sure if its updated lately, but its using MPI for communication. and I know it distributes changes in the scenegraph, such as transforms, materials transparently... Its called osgVR http://www.nbi.dk/~gronager/osgVR.html Now I know that Michael hasn't updated the code for a while, but this should certainly work as a good starting point on what you want Jan. I use to have the same issues when we were discussing the clustering of some of our applications. The problem in our apps were that the scenegraph itself was very dynamic both in terms of adding/removing nodes but also in change of transformations for many objects, interaction (events) etc... So I felt a slight burden on explicitly "cluster" such an application, in comparison of writing one app, and just specifying where the renderingnodes were. OpenSG has implemented clustering on a broad level. The whole scenegraph is designed for parallellism. That was an early decision from them. That also had a large impact on the usability and the complexity of the code, whenever a part of the scene is changed it is copied and the copies has to be syncronized, a lot of work. But they had particle examples running on dozens of machines with 20.000 particles all updated on one machine and reflected without any explicit distributioncode in the app... I said in the beginning we had some issues with the thought of having to do explicit clustering, but now with Quad DualCore, multiGPU machines, who needs clustering? I told myself in the beginning of 2001, dont do clustering, just wait for the next generation onyx, and now they are here! For a small sub-fraction of the price :-) /Anders On 10/10/06, Don Burns <[EMAIL PROTECTED]> wrote: Hi Jan,On 10/9/06, Jan Ciger < [EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE-Hash: SHA1Hello,Don Burns wrote:> The luxury we have with many graphics clusters is that we can impose a> master/slave architecture, where the slaves are simply readers. Only the > master writes to shared buffers, and the slaves simply receive the updates> at frame synchronization time.This is pretty much what I had in mind. The rendering slaves do not needto update the scene graph themselves, so it is a one-way affair simplifying the synchronization process quite a bit.> I think what you've described is a simple master-writer/slave-reader> architecture.Yes, I think that would be most appropriate for this case. > To make a humvee move, for> example, you call>>matrixTransform->setMatrix(matrix);>> where matrixTransform is the node that moves the vehicle and matrix is> where > the data containing the vehicle's position and attitude is stored for this> frame. In this case, 'matrix' can be allocated in the cluster's shared> memory pool (shared between nodes), but matrixTransform does not need to > be.This was what I was thinking about when I wrote about the ad-hocsolution. Is there a toolkit able to do this? (synchronize some sort ofnetwork shared memory). I guess that this is what VR Juggler does and I could probably find some more online as well. Probably even MPI coulddo. Do you have some preferred tool to do this sort of work? I'm afraid I cut my teeth on low level network programming and most tools feel like overkill for this kind of application. The osgcluster example was written by an example I gave Robert a while back and is very simple. In this case, it sends nothing more than the eyepoint. But how much data you send is just a matter of data size. UDP (DATAGRAM) packets can send up to a configurable (and queriable) amount of data per packet. (I think the default is around 1540 bytes, or something like that). In the simple case, your data can fit into one packet, which can be sent every frame (about 12 double matricies, or 24 single precision matrices). Anyway, for me, this is such low hanging fruit that I just do the simple (some times adhoc) method. In fact, a solution could have been written in about the time it takes to write this email thread. > Further, a simple update callback on matrixTransform can effect an > automatic update of the vehicle's position. You need only , then, > synchronize the shared buffers before calling the update traversal.Ah, neat. I didn't think about using the update callback to do this. Nice.> At the top level of the application then, running on the master, simply > updates the position of the vehicles, etc. synchronizes the shared buffers> and the positions are updated in graphics about a frame and a half later.>What about active stereo? Wouldn't this delay cause problems? AFAIK, for active stereo the rendering nodes have to be synchronizedframe-by-frame, otherwise the stereo falls apart at the edges of thewalls of the CAVE. This actually becomes a hardware video sync problem. It really is a different level of synchronization than the data sync. I cover some of that in this article: http://www.donburns.net/OSG/Article
