[osg-users] How do I generate wrappers ?
Hello !! Concerning osgIntrospection, I'm reading everywhere that I can generate the wrappers for my own classes, can someone tell me where I can find information on how to do this ? (and where can i find the wrapper generator...) Manu. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] How do I generate wrappers ?
Thanks !! I finally found something :-) Manu. 2007/7/18, Robert Osfield [EMAIL PROTECTED]: Hi Manu, Have search on the wiki for genwrapper. On 7/18/07, Emmanuel Roche [EMAIL PROTECTED] wrote: Hello !! Concerning osgIntrospection, I'm reading everywhere that I can generate the wrappers for my own classes, can someone tell me where I can find information on how to do this ? (and where can i find the wrapper generator...) Manu. ___ 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 mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] osgViewer include directory missing in OSG-2.0 windows binaries (zip file)
Hello ! as written in the title, it seems to me that the include directory for osgViewer is missing in windows binaries (zipped version) for OpenSceneGraph 2.0 Manu. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: about osgIntrospection...
Well... I'll be waiting then... :-) I have no other choose anyway :-D Manu. 2007/7/16, David Callu [EMAIL PROTECTED]: Hi Emmanuel, I don't find good way to do what you want. osgIntrospection::Value take a variable in constructor parameter and reflect this variable. To discover the type of a pointer, osgIntrospection use the RTTI mechanism. So the variable give in parameter of the constructor couldn't be a void *. The intuitive way that I will take is to request the osg::Geode type to osgIntrospection::Reflection (ok possible). Create a Null instance of this type (never try but normally possible), and finally request to osgIntrospection the conversion of void* in osg::Geode* (actually not possible). To do this, we must add a osgIntrospection::ReinterpretConverter in each Reflector, I will do this and test it but I really busy this week so I push back this to the next week end. If somebody have a better solution, I listening. David Callu ___ 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] Is osgLua okay ?
Well I tried this also (actually I couldn't load the lua plugin dynamically
so I try including all the sources in my program), but in the function
you're speaking about we have :
if (lua_isuserdata(L, index))
{
Value *v = Value::get(L, index);
if (v) return v-get();
else
{
luaL_error(L,
userdata can not be used as osgIntrospection::Value);
}
}
-- and according to me this userdata can not be used as
osgIntrospection::Value is not an easy first solution to skip that case,
it's really that the conversion is not possible right now (I wrote an other
thread on this point : how to convert a void pointer with only the class
name through osgintrospection...).
So, what i mean is: suppose you have a class binded to lua (with tolua++ for
example, so represented as specific userdata) like MyDrawable, derived from
osg::Drawable. Suppose you have loaded osgLua with osg wrapper, you cannot
do something like:
local g = osg.Geode() -- This is OK: using osg wrapper, building g as a
osg::Geode introspection value
local d = MyDrawable:new() -- this is OK: using tolua to build a userdata
wrapping the C++ pointer
g:addDrawable(d) -- ERROR : as an introspection Value, g expects other
introspection values as arguments for method calls... and, again, correct me
if I'm wrong, but there is no way to convert d (a void pointer + the name
MyDrawable as metadata somewhere) to an osgIntrospection::Value
dynamically... snif.
Manu.
2007/7/16, Ole-Morten Duesund [EMAIL PROTECTED]:
Emmanuel Roche wrote:
There is still one major problem yet (at least for me) : you cannot mix
osg object built in lua with introspection and osg objects build in Lua
without introspection... and you can't even update osgLua to change this
: it is not possible to build and osgIntrospection::Value from a lu
userdata (void* !!!) as far as I know... :-(
That's not really true. Admittedly I cheated, but.
I included the osgLua/Value.h in my installation of osgLua. This gives
me nice things like :
osgIntrospection::Value osgLua::getValue(lua_State *L, int index)
Undoubtedly there are better/more sensible ways to do it. But this works
as well.
- OM
___
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] Is osgLua okay ?
Thanks for this information ! I guess the patch you're speaking about are simple compilation issues due to changes in osg 2.0 API, or is there an official osgLua patch somewhere ? Manu. 2007/7/13, Ole-Morten Duesund [EMAIL PROTECTED]: We're using osgLua at work and we're very happy with it. For now you'll need to patch it to get it to work with osg2.0. Also, be aware that instantiating osg object via osgLua is slow. I can't really say if this is an osgLua or osgIntrospection/osgWrapper issue. Apart from this, it's great. And certainly easier than rolling your own. Not to mention, depending on osgIntrospection should be a lot more future-proof than maintaining your own bindings. - OM ___ 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] about osgIntrospection...
Hmmm... sorry for this question if it is a stupid one, but I really don't know how to proceed: suppose I have a void pointer (void* myObject for example) and the name describing what this pointer is (osg::Geode for example) is there a solution to build a osgIntrospection::Value from this ? I mean, an osgIntrospection::Value knowing it is an osg::Geode, so I guess not simply built from the void pointer :-( Manu. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Re: about osgIntrospection...
In fact, what I would need is a way to access the class using the name... (like in java)... but I'm don't think this is possible... is it ? snif. Manu. 2007/7/13, Emmanuel Roche [EMAIL PROTECTED]: Hmmm... sorry for this question if it is a stupid one, but I really don't know how to proceed: suppose I have a void pointer (void* myObject for example) and the name describing what this pointer is (osg::Geode for example) is there a solution to build a osgIntrospection::Value from this ? I mean, an osgIntrospection::Value knowing it is an osg::Geode, so I guess not simply built from the void pointer :-( Manu. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Is osgLua okay ?
There is still one major problem yet (at least for me) : you cannot mix osg object built in lua with introspection and osg objects build in Lua without introspection... and you can't even update osgLua to change this : it is not possible to build and osgIntrospection::Value from a lu userdata (void* !!!) as far as I know... :-( Manu. The only possible escape I see for me would be to generate 2007/7/13, Ole-Morten Duesund [EMAIL PROTECTED]: Emmanuel Roche wrote: Thanks for this information ! I guess the patch you're speaking about are simple compilation issues due to changes in osg 2.0 API, or is there an official osgLua patch somewhere ? Yes, it's the compilation stuff. No official patch anywhere that I know of. - OM ___ 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] Is osgLua okay ?
Hello there !! I'm planning to use osgLua to integrate OSG in lua scripts from now on, but I just wanted to ask before: did any one fully experience this before ? The author says this is an experimental project, are there any known bugs or memory leaks issue left ? On the whole : is this a good idea ? :-) [Currently I'm using tolua++ to bind to OSG classes in Lua... working great, but a lot of work to do by hand, that's why I would like to make the change...] Manu. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Re: about osgIntrospection...
Correct me if I'm wrong but, I first though that one potential solution to the initial problem I had could be to add a setType() method to the Value class... This way one could create a Value from a void pointer and then change the type But I realize it was not enough as the template internal type ( T ) would still be set to const void* :-( It there really no way to solve this ??? Manu. 2007/7/13, Emmanuel Roche [EMAIL PROTECTED]: In fact, what I would need is a way to access the class using the name... (like in java)... but I'm don't think this is possible... is it ? snif. Manu. 2007/7/13, Emmanuel Roche [EMAIL PROTECTED]: Hmmm... sorry for this question if it is a stupid one, but I really don't know how to proceed: suppose I have a void pointer (void* myObject for example) and the name describing what this pointer is (osg::Geode for example) is there a solution to build a osgIntrospection::Value from this ? I mean, an osgIntrospection::Value knowing it is an osg::Geode, so I guess not simply built from the void pointer :-( Manu. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OSGDEM ( kind of ) contest
24h ??? for 40 GB ??!... how are you doing this ? you have access to a BlueGene computer or something like that ??!! :-)... From my side I need days or even weeks to build the blue marble data (with imagery and elevation only !!!)... (for example on a standard laptop with 2Gb of ram, Geforce 7950 GTX, dual core...) Am i missing something ??? Manu. 2007/7/10, Rémy Deslignes [EMAIL PROTECTED]: Hi , I would just like to launch a little OSGDEM contest ... What is the biggest dataset you have processed with OSGDEM ? Up to now, I have processed the BlueMarble dataset : * 86400x43200 color + 21600x10800 geometry + 86400x43200 normal map + 32768x16184 clouds Which took approx 24 hours to process and produced 40 GB final data I guess of course , that I don't have the biggest dataset around ...but my obvious and evilly intent is to evaluate the potentials risks of processing a very big dataset , because I would like to process an approx 2.6Gpix * 1.3 Gpix dataset. I would then get a 4 TB dataset ... and 13 levels . Do you guys think this is feasible ? Shall the process time increase exponentially ? Do you have experience with such data ? Thanks for your experiences -- Remy Deslignes Ingenieur Developement / Software Engineer Tel: +33 (0)1.53.90.11.19 === Silicon Worlds S.A. 224, rue Saint Denis 75002 Paris France Tel: +33 (0)1.53.90.11.11 Fax: +33 (0)1.53.90.11.12 http://www.silicon-worlds.fr === ___ 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] Re: problem with osg::Image::scaleImage()...
Okay : I read the mail archives and found something on this subject : a valid GL context must be active to prevent this error from happening... in this case, for example, if I have a main thread with its GL context displaying the 3D world, AND I absolutely don't want to use this thread to due stuff like image rescaling, how can I (is it even possible ?) build a gl context in my auxiliary thread with no window support at all ? Manu. 2007/7/5, Emmanuel Roche [EMAIL PROTECTED]: Hello there... I've just noticed I cannot rescale my images in the conditions I want: I'm using an auxiliary thread to execute scripts and in this script if I try to call scaleImage on a just loaded picture I always have an openGl error : not enough memory... ! except that this is not acceptable : I have a lot of memory ! And this scale operation works when I use java+jogl to start my software and display a 3D window (but even in this case, the scripts are executed in an auxiliary thread with no GL context Does anybody understand what may be happening ?... Thanks for your help ! Manu. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] problem with osg::Image::scaleImage()...
Hello there... I've just noticed I cannot rescale my images in the conditions I want: I'm using an auxiliary thread to execute scripts and in this script if I try to call scaleImage on a just loaded picture I always have an openGl error : not enough memory... ! except that this is not acceptable : I have a lot of memory ! And this scale operation works when I use java+jogl to start my software and display a 3D window (but even in this case, the scripts are executed in an auxiliary thread with no GL context Does anybody understand what may be happening ?... Thanks for your help ! Manu. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] CEGUI
By the way, sure CEGUI is not recommendable but is there another good possibility you would recommend to build GUIs in OSG ? Manu. 2007/7/3, Robert Osfield [EMAIL PROTECTED]: Hi Guy, The osgcegui example was my abortive attempt at getting CEGUI to work in a well that integrates well with the OSG. I say abortive because CEGUI really is a bit brain dead when it comes to managing multiple graphics contexts and multi-threading, its can't do it at all and doesn't look like it'll ever do it without a major rewrite. Some OSG users have got CEGUI to work with the OSG, and there are some suggestions in the osg-users archives about this. Personally I was unimpressed with CEGUI, its just not well designed or implemented library, its makes too many assumptions and restrictions on its usage to make it particularly useful beyond single window, single threaded games. I certainly wouldn't recommend it. Robert. On 7/3/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, I tried to run the osgcegui example, and no GUI was rendered. All the GUI creation code was taken from CEGUI example (which works). I didn't get any errors from CEGUI or OSG. I also tried to set the renderGUI function as post callback of the camera with no better results. any ideas? is it something with the Zbuffer? or Z position of the GUI? thanks, Guy. ___ 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 mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] osgdem error
Hello, I'm trying to build an high definition model with osgdem but I get this error when trying to add texture data : ERROR 1: Unable to compute a transformation between pixel/line and georeferenced coordinates for ../128K_BMNG/level5/tx_0_1.png. There is no affine transformation and no GCPs. Failed to reproject../128K_BMNG/level5/tx_0_1.png any idea where this could be coming from ? Manu. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Re: osgdem error
By the way here is the complete build command I use (under WinXP): osgdem -e -20 15 35 30 --range -10.00 -5.00 45.00 50.00 -d ../srtm_toulouse_saintlouis/Z_35_4.TIF -t ../128K_BMNG/level5/tx_0_1.png --range -10.00 -5.00 40.00 45.00 -d ../srtm_toulouse_saintlouis/Z_35_5.TIF -t ../128K_BMNG/level5/tx_0_1.png --range -10.00 -5.00 35.00 40.00 -d ../srtm_toulouse_saintlouis/Z_35_6.TIF -t ../128K_BMNG/level5/tx_0_1.png --range -10.00 -5.00 30.00 35.00 -d ../srtm_toulouse_saintlouis/Z_35_7.TIF -t ../128K_BMNG/level5/tx_0_1.png --range -10.00 -5.00 25.00 30.00 -d ../srtm_toulouse_saintlouis/Z_35_8.TIF -t ../128K_BMNG/level5/tx_0_1.png --range -10.00 -5.00 20.00 25.00 -d ../srtm_toulouse_saintlouis/Z_35_9.TIF -t ../128K_BMNG/level5/tx_0_1.png --range -5.00 0.00 45.00 50.00 -d ../srtm_toulouse_saintlouis/Z_36_4.TIF -t ../128K_BMNG/level5/tx_0_1.png --range -5.00 0.00 40.00 45.00 -d ../srtm_toulouse_saintlouis/Z_36_5.TIF -t ../128K_BMNG/level5/tx_0_1.png --range -5.00 0.00 35.00 40.00 -d ../srtm_toulouse_saintlouis/Z_36_6.TIF -t ../128K_BMNG/level5/tx_0_1.png --range -5.00 0.00 30.00 35.00 -d ../srtm_toulouse_saintlouis/Z_36_7.TIF -t ../128K_BMNG/level5/tx_0_1.png --range -5.00 0.00 25.00 30.00 -d ../srtm_toulouse_saintlouis/Z_36_8.TIF -t ../128K_BMNG/level5/tx_0_1.png --range -5.00 0.00 20.00 25.00 -d ../srtm_toulouse_saintlouis/Z_36_9.TIF -t ../128K_BMNG/level5/tx_0_1.png --range 0.00 5.00 45.00 50.00 -d ../srtm_toulouse_saintlouis/Z_37_4.TIF -t ../128K_BMNG/level5/tx_0_1.png --range 0.00 5.00 40.00 45.00 -d ../srtm_toulouse_saintlouis/Z_37_5.TIF -t ../128K_BMNG/level5/tx_0_1.png --range 0.00 5.00 35.00 40.00 -d ../srtm_toulouse_saintlouis/Z_37_6.TIF -t ../128K_BMNG/level5/tx_0_1.png --range 0.00 5.00 30.00 35.00 -d ../srtm_toulouse_saintlouis/Z_37_7.TIF -t ../128K_BMNG/level5/tx_0_1.png --range 0.00 5.00 25.00 30.00 -d ../srtm_toulouse_saintlouis/Z_37_8.TIF -t ../128K_BMNG/level5/tx_0_1.png --range 0.00 5.00 20.00 25.00 -d ../srtm_toulouse_saintlouis/Z_37_9.TIF -t ../128K_BMNG/level5/tx_0_1.png --range -20.00 -15.00 35.00 40.00 -d ../srtm_toulouse_saintlouis/Z_33_6.TIF -t ../128K_BMNG/level5/tx_0_1.png --range -20.00 -15.00 30.00 35.00 -d ../srtm_toulouse_saintlouis/Z_33_7.TIF -t ../128K_BMNG/level5/tx_0_1.png --range -20.00 -15.00 25.00 30.00 -d ../srtm_toulouse_saintlouis/Z_33_8.TIF -t ../128K_BMNG/level5/tx_0_1.png --range -20.00 -15.00 20.00 25.00 -d ../srtm_toulouse_saintlouis/Z_33_9.TIF -t ../128K_BMNG/level5/tx_0_1.png --range -15.00 -10.00 30.00 35.00 -d ../srtm_toulouse_saintlouis/Z_34_7.TIF -t ../128K_BMNG/level5/tx_0_1.png --range -15.00 -10.00 25.00 30.00 -d ../srtm_toulouse_saintlouis/Z_34_8.TIF -t ../128K_BMNG/level5/tx_0_1.png --range -15.00 -10.00 20.00 25.00 -d ../srtm_toulouse_saintlouis/Z_34_9.TIF -t ../128K_BMNG/level5/tx_0_1.png -l 1 -v 1 -o rtsl_ground.ive (I know I'm always using the texture tx_0_1.png but that's just for test purposes...) Manu. 2007/6/7, Emmanuel Roche [EMAIL PROTECTED]: Hello, I'm trying to build an high definition model with osgdem but I get this error when trying to add texture data : ERROR 1: Unable to compute a transformation between pixel/line and georeferenced coordinates for ../128K_BMNG/level5/tx_0_1.png. There is no affine transformation and no GCPs. Failed to reproject../128K_BMNG/level5/tx_0_1.png any idea where this could be coming from ? Manu. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] osgdem error
hmmm don't you really have any idea what the commands was like ? snif :-( Manu. 2007/6/7, Robert Osfield [EMAIL PROTECTED]: Hi Manu, This is a GDAL error. In the case of png's they don't actually have any geo-referencing info like GeoTiff's have, so perhaps this is a contribution. Try running the GDAL commands for re-projecting the data, I'm afraid I can't remember them off hand. Another thing you could try is to use GDAL to convert to a GeoTiff and add the geo ref data in. Robert. On 6/7/07, Emmanuel Roche [EMAIL PROTECTED] wrote: Hello, I'm trying to build an high definition model with osgdem but I get this error when trying to add texture data : ERROR 1: Unable to compute a transformation between pixel/line and georeferenced coordinates for ../128K_BMNG/level5/tx_0_1.png. There is no affine transformation and no GCPs. Failed to reproject../128K_BMNG/level5/tx_0_1.png any idea where this could be coming from ? Manu. ___ 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 mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] osgdem error
Thanks ! this seem to work great :-) now I just have to find how to convert my elevation tif files to a .dem file : since apparently GDAL is not handling the elevation information with my configuration... snif.. Manu. 2007/6/7, J.P. Delport [EMAIL PROTECTED]: Hi, you can add info with gdal_translate, e.g. I have saved this command for myself: #fix a tiff after its been through the gimp gdal_translate -a_srs WGS84 -a_ullr 19.1 -32.2 19.2 -32.3 infile.tif outfile.tif cheers jp Emmanuel Roche wrote: hmmm don't you really have any idea what the commands was like ? snif :-( Manu. 2007/6/7, Robert Osfield [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hi Manu, This is a GDAL error. In the case of png's they don't actually have any geo-referencing info like GeoTiff's have, so perhaps this is a contribution. Try running the GDAL commands for re-projecting the data, I'm afraid I can't remember them off hand. Another thing you could try is to use GDAL to convert to a GeoTiff and add the geo ref data in. Robert. On 6/7/07, Emmanuel Roche [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hello, I'm trying to build an high definition model with osgdem but I get this error when trying to add texture data : ERROR 1: Unable to compute a transformation between pixel/line and georeferenced coordinates for ../128K_BMNG/level5/tx_0_1.png. There is no affine transformation and no GCPs. Failed to reproject../128K_BMNG/level5/tx_0_1.png any idea where this could be coming from ? Manu. ___ osg-users mailing list osg-users@openscenegraph.net mailto:osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net mailto:osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users 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/ -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal 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 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] osgdem error
By the way, does any one knows how to do this ? (convert GeoTiff elevation to DEM... or tell osgDem GDAL than those .tif files contains elevation data)... Manu. 2007/6/7, Emmanuel Roche [EMAIL PROTECTED]: Thanks ! this seem to work great :-) now I just have to find how to convert my elevation tif files to a .dem file : since apparently GDAL is not handling the elevation information with my configuration... snif.. Manu. 2007/6/7, J.P. Delport [EMAIL PROTECTED]: Hi, you can add info with gdal_translate, e.g. I have saved this command for myself: #fix a tiff after its been through the gimp gdal_translate -a_srs WGS84 -a_ullr 19.1 -32.2 19.2 -32.3 infile.tif outfile.tif cheers jp Emmanuel Roche wrote: hmmm don't you really have any idea what the commands was like ? snif :-( Manu. 2007/6/7, Robert Osfield [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hi Manu, This is a GDAL error. In the case of png's they don't actually have any geo-referencing info like GeoTiff's have, so perhaps this is a contribution. Try running the GDAL commands for re-projecting the data, I'm afraid I can't remember them off hand. Another thing you could try is to use GDAL to convert to a GeoTiff and add the geo ref data in. Robert. On 6/7/07, Emmanuel Roche [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hello, I'm trying to build an high definition model with osgdem but I get this error when trying to add texture data : ERROR 1: Unable to compute a transformation between pixel/line and georeferenced coordinates for ../128K_BMNG/level5/tx_0_1.png. There is no affine transformation and no GCPs. Failed to reproject../128K_BMNG/level5/tx_0_1.png any idea where this could be coming from ? Manu. ___ osg-users mailing list osg-users@openscenegraph.net mailto: osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net mailto:osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users 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/ -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal 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 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] osgdem error
after -d :-) but even with something like -v 1 I sess strictly no elevation :-(... Manu. 2007/6/7, J.P. Delport [EMAIL PROTECTED]: Hi, are you using them after -d or -t? jp Emmanuel Roche wrote: By the way, does any one knows how to do this ? (convert GeoTiff elevation to DEM... or tell osgDem GDAL than those .tif files contains elevation data)... Manu. 2007/6/7, Emmanuel Roche [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Thanks ! this seem to work great :-) now I just have to find how to convert my elevation tif files to a .dem file : since apparently GDAL is not handling the elevation information with my configuration... snif.. Manu. 2007/6/7, J.P. Delport [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hi, you can add info with gdal_translate, e.g. I have saved this command for myself: #fix a tiff after its been through the gimp gdal_translate -a_srs WGS84 -a_ullr 19.1 -32.2 19.2 -32.3 infile.tif outfile.tif cheers jp Emmanuel Roche wrote: hmmm don't you really have any idea what the commands was like ? snif :-( Manu. 2007/6/7, Robert Osfield [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hi Manu, This is a GDAL error. In the case of png's they don't actually have any geo-referencing info like GeoTiff's have, so perhaps this is a contribution. Try running the GDAL commands for re-projecting the data, I'm afraid I can't remember them off hand. Another thing you could try is to use GDAL to convert to a GeoTiff and add the geo ref data in. Robert. On 6/7/07, Emmanuel Roche [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hello, I'm trying to build an high definition model with osgdem but I get this error when trying to add texture data : ERROR 1: Unable to compute a transformation between pixel/line and georeferenced coordinates for ../128K_BMNG/level5/tx_0_1.png. There is no affine transformation and no GCPs. Failed to reproject../128K_BMNG/level5/tx_0_1.png any idea where this could be coming from ? Manu. ___ osg-users mailing list osg-users@openscenegraph.net mailto:osg-users@openscenegraph.net mailto:osg-users@openscenegraph.net mailto:osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net mailto:osg-users@openscenegraph.net mailto: osg-users@openscenegraph.net mailto: osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://openscenegraph.net/mailman/listinfo/osg-users http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net mailto: 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 and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]. This message has been scanned for viruses and dangerous content
Re: [osg-users] osgdem error
hmm... okay... so I finally understood that we have multiple DEM format... in fact my source data is in GeoTiff DEM format which seem to be quite new (coming with geotiff 6.0 ?)... And I don't know is Gdal can handle this kind of data... I also found the same data in ArcInfo ASCII format... but when trying to use this in osgdem I've got infinite peaks even with small -v option... I guess there is a problem in the readen data. Does anybody knows where I coudl find free SRTM 90m data in USGS DEM format on the net ??? Manu. 2007/6/7, Emmanuel Roche [EMAIL PROTECTED]: after -d :-) but even with something like -v 1 I sess strictly no elevation :-(... Manu. 2007/6/7, J.P. Delport [EMAIL PROTECTED] : Hi, are you using them after -d or -t? jp Emmanuel Roche wrote: By the way, does any one knows how to do this ? (convert GeoTiff elevation to DEM... or tell osgDem GDAL than those .tif files contains elevation data)... Manu. 2007/6/7, Emmanuel Roche [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Thanks ! this seem to work great :-) now I just have to find how to convert my elevation tif files to a .dem file : since apparently GDAL is not handling the elevation information with my configuration... snif.. Manu. 2007/6/7, J.P. Delport [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] : Hi, you can add info with gdal_translate, e.g. I have saved this command for myself: #fix a tiff after its been through the gimp gdal_translate -a_srs WGS84 -a_ullr 19.1 -32.2 19.2 -32.3 infile.tif outfile.tif cheers jp Emmanuel Roche wrote: hmmm don't you really have any idea what the commands was like ? snif :-( Manu. 2007/6/7, Robert Osfield [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto: [EMAIL PROTECTED] mailto: [EMAIL PROTECTED]: Hi Manu, This is a GDAL error. In the case of png's they don't actually have any geo-referencing info like GeoTiff's have, so perhaps this is a contribution. Try running the GDAL commands for re-projecting the data, I'm afraid I can't remember them off hand. Another thing you could try is to use GDAL to convert to a GeoTiff and add the geo ref data in. Robert. On 6/7/07, Emmanuel Roche [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: Hello, I'm trying to build an high definition model with osgdem but I get this error when trying to add texture data : ERROR 1: Unable to compute a transformation between pixel/line and georeferenced coordinates for ../128K_BMNG/level5/tx_0_1.png. There is no affine transformation and no GCPs. Failed to reproject../128K_BMNG/level5/tx_0_1.png any idea where this could be coming from ? Manu. ___ osg-users mailing list osg-users@openscenegraph.net mailto:osg-users@openscenegraph.net mailto:osg-users@openscenegraph.net mailto:osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net mailto:osg-users@openscenegraph.net mailto: osg-users@openscenegraph.net mailto: osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://openscenegraph.net/mailman/listinfo/osg-users http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net mailto: 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
[osg-users] GraphicsWindowEmbedded ?
Hello there... just to be sure, the GraphicsWindowEmbedded system simply consists in drawing a window with no border on the designed area, isn't it ?... In that case its utility is really limited I think : there is no kind of integration with the target windowing system (can't resize, hide/show window, etc...)... or am I missing something ? Manu. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] osgViewer::Viewer not receiving some Key events...
Hello there !!
I'm playing a bit with this new viewer and noticed a strange behavior :
under windows, when I use a default fullscreen viewer I receive all key
events normally in a GUIEventHandler I added to my Viewer, but, if I try to
build a windowed viewer, adding the following code:
{
osg::ref_ptrosg::GraphicsContext::Traits traits = new
osg::GraphicsContext::Traits;
traits-x = 50;
traits-y = 50;
traits-width = 640;
traits-height = 480;
traits-windowDecoration = true;
traits-doubleBuffer = true;
traits-sharedContext = 0;
osg::ref_ptrosg::GraphicsContext gc =
osg::GraphicsContext::createGraphicsContext(traits.get());
osg::ref_ptrosg::Camera camera = new osg::Camera;
camera-setGraphicsContext(gc.get());
camera-setViewport(new osg::Viewport(0,0, traits-width,
traits-height));
GLenum buffer = traits-doubleBuffer ? GL_BACK : GL_FRONT;
camera-setDrawBuffer(buffer);
camera-setReadBuffer(buffer);
// add this slave camra to the viewer, with a shift left of the
projection matrix
//viewer.setCamera(camera.get());
viewer.addSlave(camera.get(), osg::Matrixd(), osg::Matrixd());
viewer.setCameraWithFocus(camera.get());
}
(taken mainly from osgwindows sample...)
then my GUIEventHandler is not receiving the Key_Up, Down , Left and Right
events (at least !) any more... :-( (but is still receiving normal ascii
keys like 'a' or 'q' for example)... any idea what I'm missing ?
Manu.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
[osg-users] Re: osgViewer::Viewer not receiving some Key events...
In fact I guess this is still linking to the amulti threading issue : I'm
building by viewer in a Thread n°1 (- one call to createGraphicsContext()),
then I call run() in a second thread (-- call realize())...
what is the good solution in this situation ? should I prepare everything in
thread 1, call realize() here and only then call run() or frame() in thread
2 ? or should I do everything in thread 2 only ?
I'm still not understanding what's happening :-)...
Manu.
2007/6/5, Emmanuel Roche [EMAIL PROTECTED]:
Hello there !!
I'm playing a bit with this new viewer and noticed a strange behavior :
under windows, when I use a default fullscreen viewer I receive all key
events normally in a GUIEventHandler I added to my Viewer, but, if I try to
build a windowed viewer, adding the following code:
{
osg::ref_ptrosg::GraphicsContext::Traits traits = new
osg::GraphicsContext::Traits;
traits-x = 50;
traits-y = 50;
traits-width = 640;
traits-height = 480;
traits-windowDecoration = true;
traits-doubleBuffer = true;
traits-sharedContext = 0;
osg::ref_ptrosg::GraphicsContext gc =
osg::GraphicsContext::createGraphicsContext( traits.get());
osg::ref_ptrosg::Camera camera = new osg::Camera;
camera-setGraphicsContext(gc.get());
camera-setViewport(new osg::Viewport(0,0, traits-width,
traits-height));
GLenum buffer = traits-doubleBuffer ? GL_BACK : GL_FRONT;
camera-setDrawBuffer(buffer);
camera-setReadBuffer(buffer);
// add this slave camra to the viewer, with a shift left of the
projection matrix
//viewer.setCamera( camera.get());
viewer.addSlave(camera.get(), osg::Matrixd(), osg::Matrixd());
viewer.setCameraWithFocus(camera.get());
}
(taken mainly from osgwindows sample...)
then my GUIEventHandler is not receiving the Key_Up, Down , Left and Right
events (at least !) any more... :-( (but is still receiving normal ascii
keys like 'a' or 'q' for example)... any idea what I'm missing ?
Manu.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
[osg-users] Re: osgViewer::Viewer not receiving some Key events...
Okay... I made some more tests:
1) Preparing everything in thread 1 and calling realize() here, before using
thread 2 for run() is not a good solution (still not receiving Key_Up events
then !!).
2) Preparing everything in thread 2 and running there works partially
(receiving the Key_* events correctly)... yet, in fact, in thread 1 I
used to prepare everything, and also assign the scene data... if I keep it
like this, nothing is displaying (only a blue screen: this mean at least
that the viewer REALLY HAS a scene data assigned (or run() would return
immediately no ?) )... if I also assign the data in thread 2, everything is
normal... but doing things this way is completely useless since ALL is done
in thread 2, the thread 1 is not used any more and the multi threading
scheme becomes obsolete... :-(... snif !
Could I be needing something like a mutable or volatile reference to my
viewer object (I not used to those keywords yet sorry lol...) ?
Manu.
2007/6/5, Emmanuel Roche [EMAIL PROTECTED]:
In fact I guess this is still linking to the amulti threading issue : I'm
building by viewer in a Thread n°1 (- one call to createGraphicsContext()),
then I call run() in a second thread (-- call realize())...
what is the good solution in this situation ? should I prepare everything
in thread 1, call realize() here and only then call run() or frame() in
thread 2 ? or should I do everything in thread 2 only ?
I'm still not understanding what's happening :-)...
Manu.
2007/6/5, Emmanuel Roche [EMAIL PROTECTED]:
Hello there !!
I'm playing a bit with this new viewer and noticed a strange behavior :
under windows, when I use a default fullscreen viewer I receive all key
events normally in a GUIEventHandler I added to my Viewer, but, if I try to
build a windowed viewer, adding the following code:
{
osg::ref_ptrosg::GraphicsContext::Traits traits = new
osg::GraphicsContext::Traits;
traits-x = 50;
traits-y = 50;
traits-width = 640;
traits-height = 480;
traits-windowDecoration = true;
traits-doubleBuffer = true;
traits-sharedContext = 0;
osg::ref_ptrosg::GraphicsContext gc =
osg::GraphicsContext::createGraphicsContext( traits.get());
osg::ref_ptrosg::Camera camera = new osg::Camera;
camera-setGraphicsContext(gc.get());
camera-setViewport(new osg::Viewport(0,0, traits-width,
traits-height));
GLenum buffer = traits-doubleBuffer ? GL_BACK : GL_FRONT;
camera-setDrawBuffer(buffer);
camera-setReadBuffer(buffer);
// add this slave camra to the viewer, with a shift left of the
projection matrix
//viewer.setCamera( camera.get());
viewer.addSlave(camera.get(), osg::Matrixd(), osg::Matrixd());
viewer.setCameraWithFocus(camera.get());
}
(taken mainly from osgwindows sample...)
then my GUIEventHandler is not receiving the Key_Up, Down , Left and
Right events (at least !) any more... :-( (but is still receiving normal
ascii keys like 'a' or 'q' for example)... any idea what I'm missing ?
Manu.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
[osg-users] Re: osgViewer::Viewer not receiving some Key events...
Concerning the issue I had with my scene data not taken into account I found
the explanation: it came from the fact that I was adding a slave camera...
apprently the master scene data is not shared by default is it ?... any way,
if I use this simplyfied code, everything works good:
{
osg::ref_ptrosg::GraphicsContext::Traits traits = new
osg::GraphicsContext::Traits;
traits-x = 50;
traits-y = 50;
traits-width = 640;
traits-height = 480;
traits-windowDecoration = true;
traits-doubleBuffer = true;
traits-sharedContext = 0;
traits-supportsResize = true;
osg::ref_ptrosg::GraphicsContext gc =
osg::GraphicsContext::createGraphicsContext(traits.get());
osg::ref_ptrosg::Camera camera = viewer.getCamera(); // using the
existing camera directly ! :-)
camera-setGraphicsContext(gc.get());
camera-setViewport(new osg::Viewport(0,0, traits-width,
traits-height));
}
Now I will try moving this code to thread 1... as you said it should work
:-)
Manu.
2007/6/5, Emmanuel Roche [EMAIL PROTECTED]:
Okay... I made some more tests:
1) Preparing everything in thread 1 and calling realize() here, before
using thread 2 for run() is not a good solution (still not receiving Key_Up
events then !!).
2) Preparing everything in thread 2 and running there works partially
(receiving the Key_* events correctly)... yet, in fact, in thread 1 I
used to prepare everything, and also assign the scene data... if I keep it
like this, nothing is displaying (only a blue screen: this mean at least
that the viewer REALLY HAS a scene data assigned (or run() would return
immediately no ?) )... if I also assign the data in thread 2, everything is
normal... but doing things this way is completely useless since ALL is done
in thread 2, the thread 1 is not used any more and the multi threading
scheme becomes obsolete... :-(... snif !
Could I be needing something like a mutable or volatile reference to
my viewer object (I not used to those keywords yet sorry lol...) ?
Manu.
2007/6/5, Emmanuel Roche [EMAIL PROTECTED]:
In fact I guess this is still linking to the amulti threading issue :
I'm building by viewer in a Thread n°1 (- one call to
createGraphicsContext()), then I call run() in a second thread (-- call
realize())...
what is the good solution in this situation ? should I prepare
everything in thread 1, call realize() here and only then call run() or
frame() in thread 2 ? or should I do everything in thread 2 only ?
I'm still not understanding what's happening :-)...
Manu.
2007/6/5, Emmanuel Roche [EMAIL PROTECTED] :
Hello there !!
I'm playing a bit with this new viewer and noticed a strange behavior
:
under windows, when I use a default fullscreen viewer I receive all
key events normally in a GUIEventHandler I added to my Viewer, but, if I try
to build a windowed viewer, adding the following code:
{
osg::ref_ptrosg::GraphicsContext::Traits traits = new
osg::GraphicsContext::Traits;
traits-x = 50;
traits-y = 50;
traits-width = 640;
traits-height = 480;
traits-windowDecoration = true;
traits-doubleBuffer = true;
traits-sharedContext = 0;
osg::ref_ptrosg::GraphicsContext gc =
osg::GraphicsContext::createGraphicsContext( traits.get());
osg::ref_ptrosg::Camera camera = new osg::Camera;
camera-setGraphicsContext(gc.get());
camera-setViewport(new osg::Viewport(0,0, traits-width,
traits-height));
GLenum buffer = traits-doubleBuffer ? GL_BACK : GL_FRONT;
camera-setDrawBuffer(buffer);
camera-setReadBuffer(buffer);
// add this slave camra to the viewer, with a shift left of
the projection matrix
//viewer.setCamera( camera.get());
viewer.addSlave(camera.get(), osg::Matrixd(), osg::Matrixd());
viewer.setCameraWithFocus(camera.get());
}
(taken mainly from osgwindows sample...)
then my GUIEventHandler is not receiving the Key_Up, Down , Left and
Right events (at least !) any more... :-( (but is still receiving normal
ascii keys like 'a' or 'q' for example)... any idea what I'm missing ?
Manu.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
[osg-users] GraphicsWindowJava ? :-)...
Hello, I've successfully bind OSG 1.2 to Java before, to integrate an OpenGL display in a Java frame (using JOGL...)... with OSG 1.9.x the good way to do this would be to create a class GraphicsWindowJava I guess ? Have someone already try this ?... By the way, what is the state of the bindings to java now ?... I think the version of JavaOSG found on the web is quite old (for OSG 1.0 no ?), is a newer version planned soon ? Manu. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
Hmmm okay... i've just looked at the definition of USE_OSGPLUGIN(...) and I
finally understood what you mean by static object to register the
plugin...
By the way, the difference between you and me could be the compiler: I'm
using gcc-4.1.2 with a target=i686-pc-linux-gnu... i'm on FedoraCore 6,
kernel 2.6.18, and running this in VMWare workstation 5.5.3 with a WinXP
host computer.
Manu.
2007/6/1, Emmanuel Roche [EMAIL PROTECTED]:
Hi Robert !
Sorry I took so long to answer, I was absent for a few days :-). Any way,
I tried the changes you made :
- The compilation went fine, osgstaticviewer was created,
- First I noticed the function graphicwindow_X11 was commented in
osgstaticviewer.cpp,
- This function also had an empty body in GraphicWindowX11.cpp, I simply
added something like osg::GraphicsContext:setWindowingSystemInterface(new
X11WindowingSystemInterface);
And this worked for me... I tryed to start osgstaticviewer multiple times
with an .ive file and had no particular error...
if i can make a small suggestion by the way: wouldn't it be more logical
to simply have a graphicwindow() function (and a more friendly function
name or a MACRO could be even better...) rather than graphicwindow_X11()
-- we could then define this same function in GraphicWindowX11.cpp,
GraphicWindowWin32.cpp, etc... as only a single .o file is linked there
should be no conflict no ? and we would hide implementation details for this
default windowing system to the users... (they would not have to change the
function they call depending on the platform used...).
Any way, concerning your sudden pointer reset, I've trully never seen this
and have now clue either (try a linux reboot maybe :-D )...
Manu.
2007/5/25, Robert Osfield [EMAIL PROTECTED]:
Hi Manu,
I have done some experiments with the static build side, and while its
not a full solution, I've checked in a few additions. First up is
some additions to osgDB that add a proxy help class and a couple of
macros. The first macro replaces the old Proxy object usage in the
plugin, for the ive plugin it now looks like:
// now register with Registry to instantiate the above
// reader/writer.
REGISTER_OSGPLUGIN(ive, ReaderWriterIVE)
This both constructs the C++ proxy and provides the extern C void
osgdb_ive(void) function.
Then in the application you now add:
#include...
USE_OSGPLUGIN(ive)
main(...)
{
...
}
Note, the macro doesn't require you to add the function call to the
main. This is thanks the USE_OSGPLUGIN use a local C++ proxy object
to call it for you automatically.
I also copied and pasted osgviewer app across to example and called it
osgstaticviewer, this example only builds during static build. It
includes the extra plugin link line in the CMakeLists.txt as well as
the above USE_OSGPLUGIN(ive). It'll need further expanding on in
future.
I have also add a C function into GraphicsWindowX11.cpp call void
graphicswindow_X11(void), and calling of this in osgstaticviewer's
main but while it does cause the GraphicsWindowX11.o to be linked and
even the proxies to register the WindowSystemInterfaceX11, the related
static pointer in src/osg/GraphicsContext.cpp resets itself to 0 for
some unknown reason, programatically its never reset to 0, it just
happens?#!. I have now clue why it doesn't work.
Anyway, what I've checked in might inch us closer to a final easing of
making static apps.
Robert.
___
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] Re: OSG 1.9.5 static build on linux 2.6
Hi Robert !
Sorry I took so long to answer, I was absent for a few days :-). Any way, I
tried the changes you made :
- The compilation went fine, osgstaticviewer was created,
- First I noticed the function graphicwindow_X11 was commented in
osgstaticviewer.cpp,
- This function also had an empty body in GraphicWindowX11.cpp, I simply
added something like osg::GraphicsContext:setWindowingSystemInterface(new
X11WindowingSystemInterface);
And this worked for me... I tryed to start osgstaticviewer multiple times
with an .ive file and had no particular error...
if i can make a small suggestion by the way: wouldn't it be more logical to
simply have a graphicwindow() function (and a more friendly function name
or a MACRO could be even better...) rather than graphicwindow_X11() -- we
could then define this same function in GraphicWindowX11.cpp,
GraphicWindowWin32.cpp, etc... as only a single .o file is linked there
should be no conflict no ? and we would hide implementation details for this
default windowing system to the users... (they would not have to change the
function they call depending on the platform used...).
Any way, concerning your sudden pointer reset, I've trully never seen this
and have now clue either (try a linux reboot maybe :-D )...
Manu.
2007/5/25, Robert Osfield [EMAIL PROTECTED]:
Hi Manu,
I have done some experiments with the static build side, and while its
not a full solution, I've checked in a few additions. First up is
some additions to osgDB that add a proxy help class and a couple of
macros. The first macro replaces the old Proxy object usage in the
plugin, for the ive plugin it now looks like:
// now register with Registry to instantiate the above
// reader/writer.
REGISTER_OSGPLUGIN(ive, ReaderWriterIVE)
This both constructs the C++ proxy and provides the extern C void
osgdb_ive(void) function.
Then in the application you now add:
#include...
USE_OSGPLUGIN(ive)
main(...)
{
...
}
Note, the macro doesn't require you to add the function call to the
main. This is thanks the USE_OSGPLUGIN use a local C++ proxy object
to call it for you automatically.
I also copied and pasted osgviewer app across to example and called it
osgstaticviewer, this example only builds during static build. It
includes the extra plugin link line in the CMakeLists.txt as well as
the above USE_OSGPLUGIN(ive). It'll need further expanding on in
future.
I have also add a C function into GraphicsWindowX11.cpp call void
graphicswindow_X11(void), and calling of this in osgstaticviewer's
main but while it does cause the GraphicsWindowX11.o to be linked and
even the proxies to register the WindowSystemInterfaceX11, the related
static pointer in src/osg/GraphicsContext.cpp resets itself to 0 for
some unknown reason, programatically its never reset to 0, it just
happens?#!. I have now clue why it doesn't work.
Anyway, what I've checked in might inch us closer to a final easing of
making static apps.
Robert.
___
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] Re: OSG 1.9.5 static build on linux 2.6
Hi again Robert, concerning the self registering of the X11WindowingSystemInterface: no, if I remove the stuff I added it's not working anymore... And I don't see how it could work ? we are just calling an empty function in this case... how do you know the X11WindowSystemInterface was registering itself anyway ??... it seems quite impossible to me with the sources on the SVN... :-( Manu. 2007/6/1, Robert Osfield [EMAIL PROTECTED]: Hi Manu, - The compilation went fine, osgstaticviewer was created, - First I noticed the function graphicwindow_X11 was commented in osgstaticviewer.cpp, - This function also had an empty body in GraphicWindowX11.cpp, I simply added something like osg::GraphicsContext:setWindowingSystemInterface(new X11WindowingSystemInterface); Did you need to do anything in this function body, I didn't add anything because the X11WindowSystemInterface was registering itself anyway. And this worked for me... I tryed to start osgstaticviewer multiple times with an .ive file and had no particular error... Good to hear it worked. if i can make a small suggestion by the way: wouldn't it be more logical to simply have a graphicwindow() function (and a more friendly function name or a MACRO could be even better...) rather than graphicwindow_X11() -- we could then define this same function in GraphicWindowX11.cpp, GraphicWindowWin32.cpp, etc... as only a single .o file is linked there should be no conflict no ? and we would hide implementation details for this default windowing system to the users... (they would not have to change the function they call depending on the platform used...). Potentially we could have more than one GraphicsWindow* implementation on a single platfom, this is currently supported, but its technically possible and something I had in mind when I designed osgViewer. In this instance we need to be explict. For the time being I guess we could just go for the one function entry point. A macro could hide this too. Any way, concerning your sudden pointer reset, I've trully never seen this and have now clue either (try a linux reboot maybe :-D )... Reboot linux to try an fix a problem? You've obviously been too near a Windows machine recently. My guess is that their is a double initialization of the static for some reason. Robert. ___ 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] Re: OSG 1.9.5 static build on linux 2.6
Yes... I've just realized also that the plugins use the same system and seem
to work correctly... :-( really really strange... as you said, maybe it
would be a better idea not to use those proxy classes and rely simply on the
function call, no ?
In GraphicsWindowX11.cpp i was using this code:
RegisterWindowingSystemInterfaceProxy createWindowingSystemInterfaceProxy;
// declare C entry point for static compilation.
extern C {
void graphicswindow(void)
{
osg::GraphicsContext::setWindowingSystemInterface(new
X11WindowingSystemInterface);
}
}
... whereas the REGISTER_OSGPLUGIN() was creating a static proxy object...
so I tried with the following code:
static RegisterWindowingSystemInterfaceProxy
createWindowingSystemInterfaceProxy;
// declare C entry point for static compilation.
extern C {
void graphicswindow(void)
{
}
}
... but this didn't work for me :-(...
Manu.
2007/6/1, Robert Osfield [EMAIL PROTECTED]:
On 6/1/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Hi again Robert,
concerning the self registering of the X11WindowingSystemInterface: no,
if I
remove the stuff I added it's not working anymore... And I don't see how
it
could work ? we are just calling an empty function in this case...
how do you know the X11WindowSystemInterface was registering itself
anyway
??... it seems quite impossible to me with the sources on the SVN... :-(
I know because I added debug messages to the constructor of
X11WindowSystemInterface, the proxy in GraphicsWindowX11.cpp was doing
the registeration automatically as it does when you link to the
osgViewer.so, but it then was being screwed over by the static pointer
reset somehow - I've got the debug message record showing the pointer
set to the object in question, then changing back to zero without it
ever being set programmaticaly.
What is probably happening at your end is that the proxy was
registering the X11WidowSystemInterface, then the static pointer was
re-initialized, then your version of graphhicswindow_x11() function
was registering X11WindowSystemInterface.
Perhaps the solution is not to compile the proxy in static build, just
rely upon the function to it.
Curious the ive plugin is working and their is a proxy involved there
too. This suggests to be that the static Registry pointer is already
initialized in that case. Its seems to be a fluke though...
Robert.
___
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] limit Camera display framerate
Hello there, has someone already try to limit the framerate for a given osg::Camera ? In fact, just starting to use OSG 1.9, I would like to build a window with multiple Camera on the same openGl context, but with different refresh rate... is this possible ? and what would be the better starting point ? an osgCompositeViewer or and ordinary osgViewer is enough ? thanks for your help ! Manu. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] start a viewer in a non blocking way...
Hello again... I just wanted to know if there is a way to start an osgViewer::Viewer with another function than run() which is blocking, isn't it ? Or do I have to create a thread just to call this function ?... Manu. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] limit Camera display framerate
okay, and in this case, is it possible / tested to have multiple viewers on
the same OpenGL Context ?...
2007/6/1, Robert Osfield [EMAIL PROTECTED]:
Hi Many,
You wouldn't limit the framerate of an osg::Camera, but you might
limit the frame rate of a Viewer. The way to do this right now is to
change the frame loop such the frame dispatch happens are a controlled
time. i.e.
while (!viewer.done())
{
myWaitTillNextFrameShoudlBegin();
viewer.frame();
}
Robert.
On 6/1/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Hello there,
has someone already try to limit the framerate for a given osg::Camera ?
In fact, just starting to use OSG 1.9, I would like to build a window
with
multiple Camera on the same openGl context, but with different refresh
rate... is this possible ? and what would be the better starting point ?
an
osgCompositeViewer or and ordinary osgViewer is enough ?
thanks for your help !
Manu.
___
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 mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] limit Camera display framerate
Yes I see what you mean, but until now I've managed to use a context this wait with multiple osgUtil::SceneViews : you just need to be sure that those sceneviews don't overlap, then you may have a main view with a normal frame rate and auxiliary views changed only once per second for example... To be honest, I don't think this is a good solution in fact :-) It would be a lot more appropriate (I guess ?) to use a render to texture system to build small textures updated at the needed rate and apply those textures on small quads... But I must admit I haven't take the time to look at this updated solution yet :-) Manu. 2007/6/1, Robert Osfield [EMAIL PROTECTED]: On 6/1/07, Emmanuel Roche [EMAIL PROTECTED] wrote: okay, and in this case, is it possible / tested to have multiple viewers on the same OpenGL Context ?... You can multiple views that share the same graphics context, but you'll need to use a single CompositeViewer for it to ensure that the threads are sycronized. You also need to realistic, frame rate is governed by the swap buffers of a window, when you do swap buffers all cameras drawing to that window have to redrawn, you can't selectively say I just want swap buffers on one cameras viewport on that window. Robert. ___ 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] Re: OSG 1.9.5 static build on linux 2.6
Great !! I'm on this now: I will need to find how to retrieve the symbols in
lib file under linux then how to force gcc to include specific symbols, then
how to tell CMake to force gcc to do this :-)
I'll tell you as soon as I find something.
Manu.
2007/5/23, Robert Osfield [EMAIL PROTECTED]:
Forgot to mention my change is now checked in.
On 5/23/07, Robert Osfield [EMAIL PROTECTED] wrote:
Hi Manu,
My suggested change to CMakeModules/OsgMacroUtils.cmake works just
fine, both dynamic and static builds work, with both libs and plugins
compiling as static when requested.
osgviewer tells me that it can't find plugins or
windowsysteminterface, but hey you've been there before.
So how did you go about fixing these?
Robert.
On 5/23/07, Robert Osfield [EMAIL PROTECTED] wrote:
Hi Manu,
On 5/23/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
And changing this 'MODULE' variable tout STATIC leads to the
construction
of static plugin libs ! bingo !
I guess someone should include somewhere the test done for the core
libs to
decide here if we should have SHARED or STATIC... what was this
'MODULE'
used for in fact ??
The plugin macro in OpenSceneGraph/CMakeModules/OsgMacroUtils.cmake,
and the macro specifically is:
MACRO(SETUP_PLUGIN PLUGIN_NAME)
...
It should be easy to put a conditional, looking at the compile of core
libs, it looks like it should be possible to use:
IF (DYNAMIC_OPENSCENEGRAPH)
ADD_LIBRARY(${TARGET_TARGETNAME} MODULE ${TARGET_SRC}
${TARGET_H})
ELSE (DYNAMIC_OPENSCENEGRAPH)
ADD_LIBRARY(${TARGET_TARGETNAME} STATIC ${TARGET_SRC}
${TARGET_H})
ENDIF(DYNAMIC_OPENSCENEGRAPH)
I'll do a clean dynamic build, then try out the static build too.
Robert.
___
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] Re: OSG 1.9.5 static build on linux 2.6
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev ... here (apparently) every static object in each .o object file seems to have the SAME symbol (does anybody know why ???) I tried to force the link to an unique symbol set (osgViewer symbol + OSGReaderWriter symbol + 1 osgDB26RegisterDotOsgWrapperProxyD1Ev + 1 osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6Object...) but it doesn't to work for the moment... :-( Manu. 2007/5/24, E. Wing [EMAIL PROTECTED]: On 5/23/07, Emmanuel Roche [EMAIL PROTECTED] wrote: And changing this 'MODULE' variable tout STATIC leads to the construction of static plugin libs ! bingo ! I guess someone should include somewhere the test done for the core libs to decide here if we should have SHARED or STATIC... what was this 'MODULE' used for in fact ?? I missed most of the thread, but unlike Windows and ELF, Mach-O makes a hard distinction between a dynamic library and loadable bundle (a.k.a. plugin a.k.a module). CMake handles this by providing SHARED vs. MODULE. Don't use/mix-up SHARED with MODULE or Mach-O derived systems will break. -Eric ___ 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] Re: OSG 1.9.5 static build on linux 2.6
Hmmm yet it works fine for plugin with their single RegisterReaderWriterProxy object !! :-) -- I managed to start osgviewer with a .ive file !!! :-D So considering the symbol lists I already have for windows I would say that the only problematic plugins (in the common and image series at least) are osg and osgParticle Manu. 2007/5/24, Emmanuel Roche [EMAIL PROTECTED]: Okay, here are some news: - under linux we can use the command 'nm' to retrieve the symbol table from a static library: ie: nm libosgdb_osg.a osg.symbols will write the file osg.symbols then we can retrieve the valuable symbols with sed: - for osgViewer: sed -n -e s/RegisterWindowingSystemInterfaceProxy/RegisterWindowingSystemInterfaceProxy/p osgViewer.symbols osgViewer.sym -for the plugins: sed -n -e s/RegisterReaderWriterProxy/RegisterReaderWriterProxy/p -e s//RegisterDotOsgWrapperProxy/RegisterDotOsgWrapperProxy/p osg.symbols osg.sym for osgViewer I get something like: W _ZN37RegisterWindowingSystemInterfaceProxyC1Ev W _ZN37RegisterWindowingSystemInterfaceProxyD1Ev I created a simple scons project from osganimate source file, with the following file system structure: test_project build osganimate src osganimate.cpp Scontruct and as Scontruct file: Program(build/osganimate,src/osganimate.cpp, CPPFLAGS=['-g0','-O3','-pthread'], LIBPATH=[/usr/local/lib,/home/kenshin/dev/libraries/linux32/gcc-4.1.2/OSG-static-release/lib,/home/kenshin/dev/libraries/linux32/gcc- 4.1.2/OSG-static-release/lib/osgPlugins-1.9.5], CPPPATH=[/usr/local/include,/home/kenshin/dev/libraries/linux32/gcc- 4.1.2 /OpenSceneGraph-svn/include], LIBS=['osgdb_osg','osgDB','osgFX','osgParticle','osgViewer','osgGA','osgUtil','osgText','osgManipulator','osgSim','osg','OpenThreads','GLU','GL'], CPPDEFINES=['OSG_LIBRARY_STATIC','OT_LIBRARY_STATIC'], LINKFLAGS=['-u_ZN37RegisterWindowingSystemInterfaceProxyD1Ev'] ) -- As you may see the command to force gcc to include a symbol is thus '-u'+symbol linking with either the D or the C version give the save result... and... IT WORKS ! :-D ... I mean at least for the registering of the osgViewer stuff... unfortunately it is not the case for the plugins yet :-(... in fact, as valuable symbols for the osgdb_osg plugin, I retrieve something like: W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
Well, things aren't going that well unfortunately: I've just realize that every plugin that use even a single RegisterDotOsgWrapperProxy return the exact SAME symbol for this object... and I cannot find anyway to tell gcc to include the same symbol from multiple libraries (or worse from multiple objets files in a single library in the case of osg...): This means for example that we can't link with osgdb_osgText and osgdb_osgFX at the same time for example... :'( concerning the automation of the process, indeed, it's quite heavy... but I doubt there is any C function to retrieve the mangled name internally the best solution would be to use small scripts just after core and plugins libs construction to find all the needed symbols and then to include them for each sample... and for other projets... hmm... well... we can still use the generated symbols but I don't see anything better for the moment :-) Manu. 2007/5/24, Robert Osfield [EMAIL PROTECTED]: Hi Many, On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote: Hmmm yet it works fine for plugin with their single RegisterReaderWriterProxy object !! :-) -- I managed to start osgviewer with a .ive file !!! :-D So considering the symbol lists I already have for windows I would say that the only problematic plugins (in the common and image series at least) are osg and osgParticle Good to hear that you've made further progress. It would be nice to be able to automate some of this leg work. I do also wonder about the possibility of use a C functions in the plugins to allow one to grab the sybmol with the name manging, this might help the process of making things more automated. W.r.t .osg plugin and others of its type they all use an proxy mechanism for registering the ReaderWriter (read.write files) and the DotOsgWrappers (read/write the objects), its the later which is different from the rest of the plugins. Robert. ___ 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] osg::Viewport -- getViewport() function removed ?
Hello there, I've just noticed that osg::Viewport::getViewport() isn't defined anymore (in OSG 1.9.4 at least) (both definition with ints and doubles are inside a #if 0 - #endif section...) Is this normal ??? Manu. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
I'm not sure to understand : what would be this function for ? to register
the plugin in static mode ? so every sample and projects would have to call
the needed functions when starting its process (checking for static mode):
is this what you're thinking about ?
Manu.
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
HI Manu,
My thought about using C functions would be for them to be unique for
each ReaderWriter i.e :
extern C {
void osgdb_ive(void)
{
}
};
Would be added to the ive plugin, and the same goes for the other
plugins. One could possible do this via a macro when doing the proxy
instantiation just to simplify the source code. Could you try this
as a quick hack and let me know how you get on.
The .osg plugin and its dozens of DotOsgWrappers is more of a
challenge, but will be solvable using something similar.
Robert.
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Well, things aren't going that well unfortunately:
I've just realize that every plugin that use even a single
RegisterDotOsgWrapperProxy return the exact SAME symbol for this
object...
and I cannot find anyway to tell gcc to include the same symbol from
multiple libraries (or worse from multiple objets files in a single
library
in the case of osg...): This means for example that we can't link with
osgdb_osgText and osgdb_osgFX at the same time for example... :'(
concerning the automation of the process, indeed, it's quite heavy...
but I
doubt there is any C function to retrieve the mangled name internally
the best solution would be to use small scripts just after core and
plugins
libs construction to find all the needed symbols and then to include
them
for each sample...
and for other projets... hmm... well... we can still use the generated
symbols but I don't see anything better for the moment :-)
Manu.
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
Hi Many,
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Hmmm yet it works fine for plugin with their single
RegisterReaderWriterProxy object !! :-)
-- I managed to start osgviewer with a .ive file !!! :-D
So considering the symbol lists I already have for windows I would
say
that
the only problematic plugins (in the common and image series
at
least)
are osg and osgParticle
Good to hear that you've made further progress. It would be nice to
be able to automate some of this leg work. I do also wonder about the
possibility of use a C functions in the plugins to allow one to grab
the sybmol with the name manging, this might help the process of
making things more automated.
W.r.t .osg plugin and others of its type they all use an proxy
mechanism for registering the ReaderWriter (read.write files) and the
DotOsgWrappers (read/write the objects), its the later which is
different from the rest of the plugins.
Robert.
___
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 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] Re: OSG 1.9.5 static build on linux 2.6
In this case, I think we should add two functions: one to register the
readerwriter and an other to unregister it... no ? (I don't see how to
provide the same functionalities than the Register..Proxy in a single
function call...)
Manu.
2007/5/24, Emmanuel Roche [EMAIL PROTECTED]:
I'm not sure to understand : what would be this function for ? to register
the plugin in static mode ? so every sample and projects would have to call
the needed functions when starting its process (checking for static mode):
is this what you're thinking about ?
Manu.
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
HI Manu,
My thought about using C functions would be for them to be unique for
each ReaderWriter i.e :
extern C {
void osgdb_ive(void)
{
}
};
Would be added to the ive plugin, and the same goes for the other
plugins. One could possible do this via a macro when doing the proxy
instantiation just to simplify the source code. Could you try this
as a quick hack and let me know how you get on.
The .osg plugin and its dozens of DotOsgWrappers is more of a
challenge, but will be solvable using something similar.
Robert.
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Well, things aren't going that well unfortunately:
I've just realize that every plugin that use even a single
RegisterDotOsgWrapperProxy return the exact SAME symbol for this
object...
and I cannot find anyway to tell gcc to include the same symbol from
multiple libraries (or worse from multiple objets files in a single
library
in the case of osg...): This means for example that we can't link with
osgdb_osgText and osgdb_osgFX at the same time for example... :'(
concerning the automation of the process, indeed, it's quite heavy...
but I
doubt there is any C function to retrieve the mangled name internally
the best solution would be to use small scripts just after core and
plugins
libs construction to find all the needed symbols and then to include
them
for each sample...
and for other projets... hmm... well... we can still use the generated
symbols but I don't see anything better for the moment :-)
Manu.
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
Hi Many,
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Hmmm yet it works fine for plugin with their single
RegisterReaderWriterProxy object !! :-)
-- I managed to start osgviewer with a .ive file !!! :-D
So considering the symbol lists I already have for windows I would
say
that
the only problematic plugins (in the common and image series
at
least)
are osg and osgParticle
Good to hear that you've made further progress. It would be nice to
be able to automate some of this leg work. I do also wonder about
the
possibility of use a C functions in the plugins to allow one to grab
the sybmol with the name manging, this might help the process of
making things more automated.
W.r.t .osg plugin and others of its type they all use an proxy
mechanism for registering the ReaderWriter (read.write files) and
the
DotOsgWrappers (read/write the objects), its the later which is
different from the rest of the plugins.
Robert.
___
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 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] Re: OSG 1.9.5 static build on linux 2.6
yes but... thinking about it:
- if we build in static mode this means that we already know what plugins
will be used at compile time. So the code can be changed instead of changing
the symbols to include... What I mean is : instead of trying to play with
those unfriendly symbols (depends on architecture, compiler, platform,
etc... ?), since we ARE already linking with the plugin libraries anyway, on
could simply do something like:
In main project or sample file:
#ifdef OSG_LIBRARY_STATIC
extern C {
extern void register_ive();
extern void unregister_ive();
};
#endif
main() {
#ifdef OSG_LIBRARY_STATIC
register_ive();
#endif
// do what you want
// clean and quit:
#ifdef OSG_LIBRARY_STATIC
unregister_ive();
#endif
return 0;
}
at the end of the ReaderWriterIVE.cpp file:
extern C {
IVEReaderWriter* re_ive;
void register_ive(void)
{
re_ive = new IVEReaderWriter;
Registry::instance()-addReaderWriter(re_ive);
}
void unregister_ive(void)
{
Registry::instance()-removeReaderWriter(re_ive);
}
};
... I've just tested this and it works.. :-) no need to find the symbol for
the ive plugin anymore, no additional includes, just a few more code
lines... But I think this is the most friendly solution to all coders, no ?
With good macros this could even become something like:
DECLARE_PLUGIN(ive)
main() {
REGISTER_PLUGIN(ive)
// do what you want
UNREGISTER_PLUGIN(ive)
}
Manu.
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
I'm not sure to understand : what would be this function for ? to
register
the plugin in static mode ? so every sample and projects would have to
call
the needed functions when starting its process (checking for static
mode):
is this what you're thinking about ?
One would only ever use this function for the symbol it generates, its
purely a helper to you when you statically link.
Robert.
___
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] Re: OSG 1.9.5 static build on linux 2.6
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
You can't unload a static plugin... so why would you want to unload
the readerwriter?
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
In this case, I think we should add two functions: one to register the
readerwriter and an other to unregister it... no ? (I don't see how to
provide the same functionalities than the Register..Proxy in a single
function call...)
Manu.
2007/5/24, Emmanuel Roche [EMAIL PROTECTED]:
I'm not sure to understand : what would be this function for ? to
register
the plugin in static mode ? so every sample and projects would have to
call
the needed functions when starting its process (checking for static
mode):
is this what you're thinking about ?
Manu.
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
HI Manu,
My thought about using C functions would be for them to be unique
for
each ReaderWriter i.e :
extern C {
void osgdb_ive(void)
{
}
};
Would be added to the ive plugin, and the same goes for the other
plugins. One could possible do this via a macro when doing the
proxy
instantiation just to simplify the source code. Could you try this
as a quick hack and let me know how you get on.
The .osg plugin and its dozens of DotOsgWrappers is more of a
challenge, but will be solvable using something similar.
Robert.
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Well, things aren't going that well unfortunately:
I've just realize that every plugin that use even a single
RegisterDotOsgWrapperProxy return the exact SAME symbol for this
object...
and I cannot find anyway to tell gcc to include the same symbol
from
multiple libraries (or worse from multiple objets files in a
single
library
in the case of osg...): This means for example that we can't link
with
osgdb_osgText and osgdb_osgFX at the same time for example... :'(
concerning the automation of the process, indeed, it's quite
heavy...
but I
doubt there is any C function to retrieve the mangled name
internally
the best solution would be to use small scripts just after core
and
plugins
libs construction to find all the needed symbols and then to
include
them
for each sample...
and for other projets... hmm... well... we can still use the
generated
symbols but I don't see anything better for the moment :-)
Manu.
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
Hi Many,
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Hmmm yet it works fine for plugin with their single
RegisterReaderWriterProxy object !! :-)
-- I managed to start osgviewer with a .ive file !!! :-D
So considering the symbol lists I already have for windows I
would
say
that
the only problematic plugins (in the common and image
series
at
least)
are osg and osgParticle
Good to hear that you've made further progress. It would be
nice to
be able to automate some of this leg work. I do also wonder
about
the
possibility of use a C functions in the plugins to allow one to
grab
the sybmol with the name manging, this might help the process of
making things more automated.
W.r.t .osg plugin and others of its type they all use an proxy
mechanism for registering the ReaderWriter (read.write files)
and
the
DotOsgWrappers (read/write the objects), its the later which is
different from the rest of the plugins.
Robert.
___
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 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 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] Re: OSG 1.9.5 static build on linux 2.6
oups... I pressed Send too fast :-)
I just wanted to say:
Good point ! you're right: unloading the readerwriter seems useless in most
cases... (at least for me :-) ) [except maybe if someone has multiple
version of the same plugin changing dynamically... but that would be a bit
weird I guess :-)]
So, are you planning to had this C function to all plugins now ?...
I guess the same behavior could be used internally to register the
DotOsgWrappers too... I'll test that tomorrow.
Manu.
2007/5/24, Emmanuel Roche [EMAIL PROTECTED]:
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
You can't unload a static plugin... so why would you want to unload
the readerwriter?
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
In this case, I think we should add two functions: one to register the
readerwriter and an other to unregister it... no ? (I don't see how to
provide the same functionalities than the Register..Proxy in a single
function call...)
Manu.
2007/5/24, Emmanuel Roche [EMAIL PROTECTED]:
I'm not sure to understand : what would be this function for ? to
register
the plugin in static mode ? so every sample and projects would have to
call
the needed functions when starting its process (checking for static
mode):
is this what you're thinking about ?
Manu.
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
HI Manu,
My thought about using C functions would be for them to be unique
for
each ReaderWriter i.e :
extern C {
void osgdb_ive(void)
{
}
};
Would be added to the ive plugin, and the same goes for the other
plugins. One could possible do this via a macro when doing the
proxy
instantiation just to simplify the source code. Could you try
this
as a quick hack and let me know how you get on.
The .osg plugin and its dozens of DotOsgWrappers is more of a
challenge, but will be solvable using something similar.
Robert.
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Well, things aren't going that well unfortunately:
I've just realize that every plugin that use even a single
RegisterDotOsgWrapperProxy return the exact SAME symbol for this
object...
and I cannot find anyway to tell gcc to include the same symbol
from
multiple libraries (or worse from multiple objets files in a
single
library
in the case of osg...): This means for example that we can't
link with
osgdb_osgText and osgdb_osgFX at the same time for example...
:'(
concerning the automation of the process, indeed, it's quite
heavy...
but I
doubt there is any C function to retrieve the mangled name
internally
the best solution would be to use small scripts just after core
and
plugins
libs construction to find all the needed symbols and then to
include
them
for each sample...
and for other projets... hmm... well... we can still use the
generated
symbols but I don't see anything better for the moment :-)
Manu.
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
Hi Many,
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Hmmm yet it works fine for plugin with their single
RegisterReaderWriterProxy object !! :-)
-- I managed to start osgviewer with a .ive file !!! :-D
So considering the symbol lists I already have for windows I
would
say
that
the only problematic plugins (in the common and image
series
at
least)
are osg and osgParticle
Good to hear that you've made further progress. It would be
nice to
be able to automate some of this leg work. I do also wonder
about
the
possibility of use a C functions in the plugins to allow one
to grab
the sybmol with the name manging, this might help the process
of
making things more automated.
W.r.t .osg plugin and others of its type they all use an proxy
mechanism for registering the ReaderWriter ( read.write files)
and
the
DotOsgWrappers (read/write the objects), its the later which
is
different from the rest of the plugins.
Robert.
___
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 mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org
[osg-users] Re: OSG 1.9.5 static build on linux 2.6
I finished this first build test (static core libs + shared plugin libs): two remarks: 1) the example osgDepthShadow won't compile: [ 88%] Building CXX object examples/osgdepthshadow/CMakeFiles/example_osgdepthshadow.dir/osgdepthshadow.o Linking CXX executable ../../bin/osgdepthshadow /home/kenshin/dev/libraries/linux32/gcc-4.1.2/OpenSceneGraph-1.9.5 /lib/libosgShadow.a(ShadowMap.o):(.data+0x0): multiple definition of `fragmentShaderSource_noBaseTexture' CMakeFiles/example_osgdepthshadow.dir/osgdepthshadow.o:(.data+0x0): first defined here /home/kenshin/dev/libraries/linux32/gcc-4.1.2/OpenSceneGraph-1.9.5 /lib/libosgShadow.a(ShadowMap.o):(.data+0xe0): multiple definition of `fragmentShaderSource_withBaseTexture' CMakeFiles/example_osgdepthshadow.dir/osgdepthshadow.o:(.data+0xe0): first defined here collect2: ld a retourné 1 code d'état d'exécution make[2]: *** [bin/osgdepthshadow] Erreur 1 .. obviously this is linked to the static build process... 2) I have the same problem than I had under WinXP at the beginning: when I try to run osganimate I get: [EMAIL PROTECTED] bin]$ ./osganimate Warning: Could not find plugin to read objects from file glider.osg. Warning: Could not find plugin to read objects from file cessna.osg. View::setUpViewAcrossAllScreens() : Error, no WindowSystemInterface available, cannot create windows. Viewer::realize() - failed to set up any windows -- the auto referencing of the GraphicWindowX11 interface doesn't happen neither :-) By the way, Is someone else working on this static build process or am I on my own... ? I guess I have to find out a bit more about CMake and linux symbols anyway... regards, Manu. 2007/5/23, Emmanuel Roche [EMAIL PROTECTED]: Hello ! I'm trying to build this release of OSG on linux this time. First thing noticable: the plugins are still built as shared libraries (in mode OPENSCENEGRAPH_DYNAMIC=OFF)... is this normal ?? I've got a question any way: On windows, when I was trying to use .dll for the plugins mixed with static core libraries it didn't work: I'm not un expert, but I guess this could have something to do with static objects in osgDB.lib existing in two places (the application and the plugin) and not being shared as one would expect (please tell me if this explanation is totally wrong :-) ). So I came to the conclusion that everything must be shared or static... is this still true under linux with gcc ??? if it is, then it means we have to build static plugin libs and then to force the compiler to include the needed symbols again... (correct me if I'm wrong but I think that current gcc versions (4.1 at least...) perform function level linking by default). Does anyone know how to retrieve the symbol list from the librairy ? (ie: what is the corresponding command for MS dumpbin.exe ? :-)) still if my previous assumption is true for linux, could someone just tell me what should be changed in order to built static plugin libs in the Cmake files ? Now, if this assumption is wrong, it would mean that I should expect this current compilation (static core libs + shared plugin libs) to work just fine ? regards, Manu. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
It's good ! the correction you made solved the problem for osgdepthshadow sample ! :-) Manu. 2007/5/23, Emmanuel Roche [EMAIL PROTECTED]: Okay, the compilation is in progress... Now, is there a simple way to force Cmake to build static libs for the plugins ? I really don't understand nothing to those files lol... Manu. 2007/5/23, Robert Osfield [EMAIL PROTECTED]: On 5/23/07, Emmanuel Roche [EMAIL PROTECTED] wrote: By the way, Is someone else working on this static build process or am I on my own... ? I guess I have to find out a bit more about CMake and linux symbols anyway... You may well be the first under Windows and Unix :-) W.r.t the multiple definitions in osgShadow/osgdepthshadow example, I've just made the local definiations of the shaders static in the osgShadow and checked it in. Could you let me know if this fixes it. Robert. ___ 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] Re: OSG 1.9.5 static build on linux 2.6
Okay, the compilation is in progress... Now, is there a simple way to force Cmake to build static libs for the plugins ? I really don't understand nothing to those files lol... Manu. 2007/5/23, Robert Osfield [EMAIL PROTECTED]: On 5/23/07, Emmanuel Roche [EMAIL PROTECTED] wrote: By the way, Is someone else working on this static build process or am I on my own... ? I guess I have to find out a bit more about CMake and linux symbols anyway... You may well be the first under Windows and Unix :-) W.r.t the multiple definitions in osgShadow/osgdepthshadow example, I've just made the local definiations of the shaders static in the osgShadow and checked it in. Could you let me know if this fixes it. Robert. ___ 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] Re: OSG 1.9.5 static build on linux 2.6
Concerning the build process for the plugins I think I finally have a clue: everything seems to come to the function ADD_LIBRARY in the CMake files... for the core libs, the second parameter for this function can apparently be SHARED or STATIC depending on the configuration whereas for the plugins, it seems to always be the variable 'MODULE' :-). I keep digging... :-) Manu. 2007/5/23, Emmanuel Roche [EMAIL PROTECTED]: It's good ! the correction you made solved the problem for osgdepthshadow sample ! :-) Manu. 2007/5/23, Emmanuel Roche [EMAIL PROTECTED] : Okay, the compilation is in progress... Now, is there a simple way to force Cmake to build static libs for the plugins ? I really don't understand nothing to those files lol... Manu. 2007/5/23, Robert Osfield [EMAIL PROTECTED]: On 5/23/07, Emmanuel Roche [EMAIL PROTECTED] wrote: By the way, Is someone else working on this static build process or am I on my own... ? I guess I have to find out a bit more about CMake and linux symbols anyway... You may well be the first under Windows and Unix :-) W.r.t the multiple definitions in osgShadow/osgdepthshadow example, I've just made the local definiations of the shaders static in the osgShadow and checked it in. Could you let me know if this fixes it. Robert. ___ 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] Re: OSG 1.9.5 static build on linux 2.6
And changing this 'MODULE' variable tout STATIC leads to the construction of static plugin libs ! bingo ! I guess someone should include somewhere the test done for the core libs to decide here if we should have SHARED or STATIC... what was this 'MODULE' used for in fact ?? Manu. 2007/5/23, Emmanuel Roche [EMAIL PROTECTED]: Concerning the build process for the plugins I think I finally have a clue: everything seems to come to the function ADD_LIBRARY in the CMake files... for the core libs, the second parameter for this function can apparently be SHARED or STATIC depending on the configuration whereas for the plugins, it seems to always be the variable 'MODULE' :-). I keep digging... :-) Manu. 2007/5/23, Emmanuel Roche [EMAIL PROTECTED]: It's good ! the correction you made solved the problem for osgdepthshadow sample ! :-) Manu. 2007/5/23, Emmanuel Roche [EMAIL PROTECTED] : Okay, the compilation is in progress... Now, is there a simple way to force Cmake to build static libs for the plugins ? I really don't understand nothing to those files lol... Manu. 2007/5/23, Robert Osfield [EMAIL PROTECTED]: On 5/23/07, Emmanuel Roche [EMAIL PROTECTED] wrote: By the way, Is someone else working on this static build process or am I on my own... ? I guess I have to find out a bit more about CMake and linux symbols anyway... You may well be the first under Windows and Unix :-) W.r.t the multiple definitions in osgShadow/osgdepthshadow example, I've just made the local definiations of the shaders static in the osgShadow and checked it in. Could you let me know if this fixes it. Robert. ___ 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] OSG 1.9.4 staic build -- view problem
Hello there !! I'm still trying to build the static version of OSG (on WinXP, MSVC 2003 .NET), I built the core libs, the common plugins, retrieved the mangled names in those plugins, forced the link in the osganimate sample and tried to start the program, I suppose the plugins libs I added are correctly loaded because at the begining I had an error couldn't find plugin to read cessna.osg, etc..., and now no error anymore. Unfortunately now I get : View::setUpViewAcrossAllScreens() : Error, no WindowSystemInterface available, cannot create windows. Viewer::realize() - failed to set up any windows I suppose this is linked to the new osgViewer system but I'm not used to it :-( Any idea of what I missed here ??... regards, Manu. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Re: OSG 1.9.4 staic build -- view problem
I try to read a bit more the code sources: the problem comes from the static ref_ptrGraphicsContext::WindowingSystemInterface s_WindowingSystemInterface; not being set correctly. but where is the default value fixed for this object ? Manu. 2007/5/21, Emmanuel Roche [EMAIL PROTECTED]: Hello there !! I'm still trying to build the static version of OSG (on WinXP, MSVC 2003 .NET), I built the core libs, the common plugins, retrieved the mangled names in those plugins, forced the link in the osganimate sample and tried to start the program, I suppose the plugins libs I added are correctly loaded because at the begining I had an error couldn't find plugin to read cessna.osg, etc..., and now no error anymore. Unfortunately now I get : View::setUpViewAcrossAllScreens() : Error, no WindowSystemInterface available, cannot create windows. Viewer::realize() - failed to set up any windows I suppose this is linked to the new osgViewer system but I'm not used to it :-( Any idea of what I missed here ??... regards, Manu. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OSG 1.9.4 staic build -- view problem
Okay, thanks for the info Robert: that's the location I was looking for. You're right, now I just have to test the same force symbol include than for the plugins ;-)... Manu. 2007/5/21, Robert Osfield [EMAIL PROTECTED]: Hi Manu, The implemenation of the WindowSystemInterface auto registers itself, so even though osgViewer::Viewer does directly include GraphicsWindowWin32/X11/Carbon it is able to pick it up - but... obviously in the case of static build the compiler thinks because it isn't referenced GraphicsWindowWIn32.o etc aren't required. What you'll need to do is explictly reference the include/osgVewier/api/GraphicsWindowWin32, X11 or Carbon (which ever is native). This is the same issue as for the plugins that autoregister to are loosely coupled. Robert. On 5/21/07, Emmanuel Roche [EMAIL PROTECTED] wrote: Hello there !! I'm still trying to build the static version of OSG (on WinXP, MSVC 2003 .NET), I built the core libs, the common plugins, retrieved the mangled names in those plugins, forced the link in the osganimate sample and tried to start the program, I suppose the plugins libs I added are correctly loaded because at the begining I had an error couldn't find plugin to read cessna.osg, etc..., and now no error anymore. Unfortunately now I get : View::setUpViewAcrossAllScreens() : Error, no WindowSystemInterface available, cannot create windows. Viewer::realize() - failed to set up any windows I suppose this is linked to the new osgViewer system but I'm not used to it :-( Any idea of what I missed here ??... regards, Manu. ___ 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 mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OSG 1.9.4 staic build -- view problem
Youuhouuh ! It's working now ;-) I managed to run osganimate.exe as a single application of 2Mo :-) I keep testing the other samples, and adding plugins. Yet I have two other questions: 1) From a licensing point of view : do we have the right to use statically linked OSG libs in a commercial software ? 2) is it possible (and tested ?) to build static OSG libs under linux ? Manu. 2007/5/21, Emmanuel Roche [EMAIL PROTECTED]: Okay, thanks for the info Robert: that's the location I was looking for. You're right, now I just have to test the same force symbol include than for the plugins ;-)... Manu. 2007/5/21, Robert Osfield [EMAIL PROTECTED]: Hi Manu, The implemenation of the WindowSystemInterface auto registers itself, so even though osgViewer::Viewer does directly include GraphicsWindowWin32/X11/Carbon it is able to pick it up - but... obviously in the case of static build the compiler thinks because it isn't referenced GraphicsWindowWIn32.o etc aren't required. What you'll need to do is explictly reference the include/osgVewier/api/GraphicsWindowWin32, X11 or Carbon (which ever is native). This is the same issue as for the plugins that autoregister to are loosely coupled. Robert. On 5/21/07, Emmanuel Roche [EMAIL PROTECTED] wrote: Hello there !! I'm still trying to build the static version of OSG (on WinXP, MSVC 2003 .NET), I built the core libs, the common plugins, retrieved the mangled names in those plugins, forced the link in the osganimate sample and tried to start the program, I suppose the plugins libs I added are correctly loaded because at the begining I had an error couldn't find plugin to read cessna.osg, etc..., and now no error anymore. Unfortunately now I get : View::setUpViewAcrossAllScreens() : Error, no WindowSystemInterface available, cannot create windows. Viewer::realize() - failed to set up any windows I suppose this is linked to the new osgViewer system but I'm not used to it :-( Any idea of what I missed here ??... regards, Manu. ___ 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 mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OSG 1.9.4 staic build -- view problem
hello again Robert, I have compiled osgviewer, and facing a small problem : it works but pressing h or s displays the texts with no formating and the console writes cannot find plugin to read /path/to/arial.ttf. Yet I'm already linking with osgdb_osgText.lib and forcing the symbol to the RegisterDotOsgWrapperProxy Text_Proxy object. (another thing is that the compile doesn't complain if I omit freetype219.lib... very strange...). Do you have any idea what's missing ? Manu. 2007/5/21, Robert Osfield [EMAIL PROTECTED]: On 5/21/07, Emmanuel Roche [EMAIL PROTECTED] wrote: Youuhouuh ! It's working now ;-) I managed to run osganimate.exe as a single application of 2Mo :-) I keep testing the other samples, and adding plugins. Good to hear. Any chance of use seeing some update CMakeLists.txt files :-) Yet I have two other questions: 1) From a licensing point of view : do we have the right to use statically linked OSG libs in a commercial software ? Yes, that's the purpose of the OSGPL rather than LGPL. Some plugins aren't OSGPL'd though, but most are. For instance the 3ds plugin is LGPL, the Inventor plugin is GPL'd if you use Coin (or dual licensed), and the xine plugin is GPL'd. 2) is it possible (and tested ?) to build static OSG libs under linux ? I haven't tried a static build yet under Linux, I was waiting to see how you got on :-) Robert. ___ 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] OSG 1.9.4 staic build -- view problem
hmmm... well sorry :-) I've just realize that what's really missing is the freetype plugin !!... I must have missed this one in Cmake configuration, do not take the previous mail into account :-) Manu. 2007/5/21, Emmanuel Roche [EMAIL PROTECTED]: hello again Robert, I have compiled osgviewer, and facing a small problem : it works but pressing h or s displays the texts with no formating and the console writes cannot find plugin to read /path/to/arial.ttf. Yet I'm already linking with osgdb_osgText.lib and forcing the symbol to the RegisterDotOsgWrapperProxy Text_Proxy object. (another thing is that the compile doesn't complain if I omit freetype219.lib... very strange...). Do you have any idea what's missing ? Manu. 2007/5/21, Robert Osfield [EMAIL PROTECTED] : On 5/21/07, Emmanuel Roche [EMAIL PROTECTED] wrote: Youuhouuh ! It's working now ;-) I managed to run osganimate.exe as a single application of 2Mo :-) I keep testing the other samples, and adding plugins. Good to hear. Any chance of use seeing some update CMakeLists.txt files :-) Yet I have two other questions: 1) From a licensing point of view : do we have the right to use statically linked OSG libs in a commercial software ? Yes, that's the purpose of the OSGPL rather than LGPL. Some plugins aren't OSGPL'd though, but most are. For instance the 3ds plugin is LGPL, the Inventor plugin is GPL'd if you use Coin (or dual licensed), and the xine plugin is GPL'd. 2) is it possible (and tested ?) to build static OSG libs under linux ? I haven't tried a static build yet under Linux, I was waiting to see how you got on :-) Robert. ___ 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] Static version of OSG 1.9.4
Hello there, I've been trying to compile the static version of OSG 1.9.4 with Cmake on WinXP, MSVC 2003 .NET (settings Dynamic OSG and Dynamic OpenThreads to OFF in CMake configuration) but unfortunately it's not working: as far as I can say the preprocessor defines OSG_LIBRARY_STATIC are not set in plugins and example projects and neither is OT_LIBRARY_STATIC in all basic libs, examples and plugins... I guest this should be easy to change but I'm not use to CMake so I prefer waiting for an official update :-). An other point is that osgManipulator Export file doesn't seem to handle the OSG_LIBRARY_STATIC case at all ;-). I read on the website this static build was still to be tested, I hope this will help speeding up to correction. regards. Manu. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] glGetString error
Okay, so this just normal, and we can't do anything about it. Thanks for the answer Paul, I just wanted to be sure :-) regards, Emmanuel. 2007/4/17, Paul Martz [EMAIL PROTECTED]: 2) Second case: (problem) - I create a thread 1, create a producer::RenderSurface and DO realize it in this thread, I also call the init() function of my associated SceneView() [otherwise it would be called in the cull() function, and would crash in my second thread...], then I start my Thread 2. This sounds about right, because the realize() call made the rendering context current to thread 1. Thread 2 doesn't have a rendering context. -Paul ___ 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] glGetString error
Hi there, I'm still with my multithreading questions :-)
I'm testing two scenarios :
1) First case: (witness case)
- I create a thread 1, create a Producer::RenderSurface, but do NOT realize
it.
- In thread 1, I start an other Thread 2.
- In thread 2, I realize the previous RenderSurface, I call the init()
function of an associated osgUtil::SceneView (this point is optional, the
automatic call for init() works in this case), then I call cull() and draw()
in a loop.
== With this scenario, everything works well.
2) Second case: (problem)
- I create a thread 1, create a producer::RenderSurface and DO realize it in
this thread, I also call the init() function of my associated SceneView()
[otherwise it would be called in the cull() function, and would crash in my
second thread...], then I start my Thread 2.
- In thread 2, I (try to...) call cull() and draw() in a loop...
== I solved a first crash in cull() by calling SceneView::init() in the
first thread, but now, I have a crash in the draw() function: when first
applying a LightModel attribute to the state apparently in this function:
void LightModel::apply(State) const
{
glLightModelfv(GL_LIGHT_MODEL_AMBIENT,_ambient.ptr());
//static bool s_separateSpecularSupported = strcmp((const char
*)glGetString(GL_VERSION),1.2)=0;
static bool s_separateSpecularSupported = (std::string((const
char*)glGetString(GL_VERSION)) ==
1.2);
if (s_separateSpecularSupported)
{
if (_colorControl==SEPARATE_SPECULAR_COLOR)
{
glLightModeli(GL_LIGHT_MODEL_COLOR_CONTROL,GL_SEPARATE_SPECULAR_COLOR);
}
else
{
glLightModeli(GL_LIGHT_MODEL_COLOR_CONTROL,GL_SINGLE_COLOR);
}
}
glLightModeli(GL_LIGHT_MODEL_LOCAL_VIEWER,_localViewer);
glLightModeli(GL_LIGHT_MODEL_TWO_SIDE,_twoSided);
}
== the function glGetString(GL_VERSION) returns NULL :'( !!!
... I guess it has something to do with OpenGL not being aware of its
initialization in the second thread... but I really have no clue how to
solve this (if it's even possible... !).
I think using the new osgViewer implementation might help, but I'm not ready
yet to take this change, any idea how to do this another way ?
regards,
Emmanuel.
PS: using OSG 1.2, WinXP, Nvidia Geforce 7900 GS.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
[osg-users] Vertex attribute names ?
Hello !! I'm trying to generate the tangent,binormal,normal base for a GLSL parallax shader. I would need to provide the tangent and binormal vectors as attribute (in GLSL grammar)... I checked OSG source : apparently I need to use the TangentSpaceGenerator class to build the arrays, but then, in osg::Geometry I can only use setVertexAttribArray(unsigned int index,Array* array) I guess, so the array would be associated to an index number and not a name, could someone explain me how to do the following step (link this index number to the wanted name I guess...) ? thanks in advance :-) regards, Emmanuel. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Vertex attribute names ?
Okay, in this case, is someone aware of a solution to access those attributes in GLSL anyway through their index ? I guess I'm not the first one trying to use attributes no lol ? I think there is one solution at least (and that's the one I'm going to use if I find nothing better...) : I could use to built in attribute variables ( gl_Color, gl_SecondaryColor, gl_MultiTexCoord0 to 7)... which can be assigned with OSG functions (setColorArray, etc...). But I really think this is not a good final solution... regards, Emmanuel. 2007/4/11, Robert Osfield [EMAIL PROTECTED]: Hi Emmanuel, The OSG doesn't presently support naming of vertex attributes, only use of indexes. Naming of vertex attributes is a bit of awkward issue as the way the naming is set up in OpenGL prevents one from display listing geometry, and display listing of geometry is what the OSG does by default for performance reasons. This area is a bit of an oddity in OpenGL. Robert. On 4/11/07, Emmanuel Roche [EMAIL PROTECTED] wrote: Hello !! I'm trying to generate the tangent,binormal,normal base for a GLSL parallax shader. I would need to provide the tangent and binormal vectors as attribute (in GLSL grammar)... I checked OSG source : apparently I need to use the TangentSpaceGenerator class to build the arrays, but then, in osg::Geometry I can only use setVertexAttribArray(unsigned int index,Array* array) I guess, so the array would be associated to an index number and not a name, could someone explain me how to do the following step (link this index number to the wanted name I guess...) ? thanks in advance :-) regards, Emmanuel. ___ 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 mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] TangentSpaceGenerator giving null normal vector...
Hi, I'm using the TangentSpaceGenerator on a sphere geometry (one primitiveset in Triangle_strip), and I added a small part of the result to the end of this mail : is it correct that some points have a null normal (0,0,0) regards, Emmanuel. 10:58:37: INFO: The normal is: (-0.102244,0.021733,0.994522) 10:58:37: INFO: The normal is: (-0.207912,-0.00,0.978148) 10:58:37: INFO: The normal is: (-0.104528,0.00,0.994522) 10:58:37: INFO: The normal is: (-0.102244,-0.021733,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.095492,-0.042516,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.084565,-0.061440,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.069943,-0.077680,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.052264,-0.090524,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.032301,-0.099412,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.010926,-0.103956,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.010926,-0.103956,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.032301,-0.099412,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.052264,-0.090524,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.069943,-0.077680,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.084565,-0.061440,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.095492,-0.042516,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.102244,-0.021733,0.994522) 10:58:37: INFO: The normal is: (-0.00,0.00,1.00) 10:58:37: INFO: The normal is: (0.104528,-0.00,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.102244,0.021733,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.095492,0.042516,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.084565,0.061440,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.069943,0.077680,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.052264,0.090524,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.032301,0.099412,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.010926,0.103956,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.010926,0.103956,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.032301,0.099412,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.052264,0.090524,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.069943,0.077680,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.084565,0.061440,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.095492,0.042516,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.102244,0.021733,0.994522) 10:58:37: INFO: The normal is: (0.00,-0.00,1.00) 10:58:37: INFO: The normal is: (-0.104528,-0.00,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,1.00) ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] TangentSpaceGenerator giving null normal vector...
Yes :-) Indeed, this would be a good explanation. Thanks Robert ! Emmanuel. 2007/4/11, Robert Osfield [EMAIL PROTECTED]: Hi Emmanuel, My guess is that there are some zero area triangles in the geometry. The TangentSpaceGenerator will have a hard time handling these - the tangent space is undefined. Robert. On 4/11/07, Emmanuel Roche [EMAIL PROTECTED] wrote: Hi, I'm using the TangentSpaceGenerator on a sphere geometry (one primitiveset in Triangle_strip), and I added a small part of the result to the end of this mail : is it correct that some points have a null normal (0,0,0) regards, Emmanuel. 10:58:37: INFO: The normal is: (-0.102244,0.021733,0.994522) 10:58:37: INFO: The normal is: (-0.207912,-0.00,0.978148) 10:58:37: INFO: The normal is: (-0.104528,0.00,0.994522) 10:58:37: INFO: The normal is: (-0.102244,-0.021733,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.095492,-0.042516,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.084565,-0.061440,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.069943,-0.077680,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.052264,-0.090524,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.032301,-0.099412,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.010926,-0.103956,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.010926,-0.103956,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.032301,-0.099412,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.052264,-0.090524,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.069943,-0.077680,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.084565,-0.061440,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.095492,-0.042516,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.102244,-0.021733,0.994522) 10:58:37: INFO: The normal is: (-0.00,0.00,1.00) 10:58:37: INFO: The normal is: (0.104528,-0.00,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.102244,0.021733,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.095492,0.042516,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.084565,0.061440,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.069943,0.077680,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.052264,0.090524,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.032301,0.099412,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (0.010926,0.103956,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.010926,0.103956,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.032301,0.099412,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.052264,0.090524,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.069943,0.077680,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.084565,0.061440,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.095492,0.042516,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,0.00) 10:58:37: INFO: The normal is: (-0.102244,0.021733,0.994522) 10:58:37: INFO: The normal is: (0.00,-0.00,1.00) 10:58:37: INFO: The normal is: (-0.104528,-0.00,0.994522) 10:58:37: INFO: The normal is: (0.00,0.00,1.00) ___ 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
Re: [osg-users] Vertex attribute names ?
Thanks, I guess this means that the function osg::Program::addBindAttribLocation(std::string, index) is what I was looking for :-). regards, Emmanuel. 2007/4/11, Mike Weiblen [EMAIL PROTECTED]: Hi, See the compactdisc.osg and compactdisc-texcoord.osg examples in osgtoy (http://osgtoy.cvs.sourceforge.net/osgtoy/osgtoy/osgtoy-data/) They differ only in how they send the tangent vectors: the former uses a generic GLSL attribute, the latter sends the tangent in a built-in texcoord. (ATI drivers have (had?) a bug such that any use of generic attributes caused all geometry to vanish! Hence the need for the built-in attribute variation) cheers -- mew Emmanuel Roche wrote: Okay, in this case, is someone aware of a solution to access those attributes in GLSL anyway through their index ? I guess I'm not the first one trying to use attributes no lol ? I think there is one solution at least (and that's the one I'm going to use if I find nothing better...) : I could use to built in attribute variables ( gl_Color, gl_SecondaryColor, gl_MultiTexCoord0 to 7)... which can be assigned with OSG functions (setColorArray, etc...). But I really think this is not a good final solution... regards, Emmanuel. 2007/4/11, Robert Osfield [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hi Emmanuel, The OSG doesn't presently support naming of vertex attributes, only use of indexes. Naming of vertex attributes is a bit of awkward issue as the way the naming is set up in OpenGL prevents one from display listing geometry, and display listing of geometry is what the OSG does by default for performance reasons. This area is a bit of an oddity in OpenGL. Robert. On 4/11/07, Emmanuel Roche [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hello !! I'm trying to generate the tangent,binormal,normal base for a GLSL parallax shader. I would need to provide the tangent and binormal vectors as attribute (in GLSL grammar)... I checked OSG source : apparently I need to use the TangentSpaceGenerator class to build the arrays, but then, in osg::Geometry I can only use setVertexAttribArray(unsigned int index,Array* array) I guess, so the array would be associated to an index number and not a name, could someone explain me how to do the following step (link this index number to the wanted name I guess...) ? thanks in advance :-) regards, Emmanuel. -- Mike Weiblen -- Austin Texas USA -- http://mew.cx/ ___ 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] OSG simplifier question...
Okay, but, pushing this to an extreme : imagine I have a quad geometry for example, if I use a low enough ratio I shouldn't see anything left, no ? Or can't the simplifier suppress all vertices from a geometry ? Emmanuel 2007/4/10, Robert Osfield [EMAIL PROTECTED]: Hi Emmanuel, The osgUtil::Simplifier can only simplify individual osg::Geometry, it won't group separate geometries together and simplify them as a group. Robert. On 4/10/07, Emmanuel Roche [EMAIL PROTECTED] wrote: Hello there, I'm facing a really strange situation : I've got a model I'm trying to run osgsimplifier on, and apparently I cannot simplify it as much as I want !! I tried every kind of parameters (playing with --ratio and --max-error)... but every time, the model is simplified just a little bit and every attempt to simplify it more give the same result... When I try the same things on the cessna.osg model everything seems to work normaly (using a ratio of 0.01 really crush the polygons as one would except...). So I guess the problem comes from somthing not understood by the simplifier visitor in my model file (can't traverse MatrixTransform ??) ? I'm joining the model if someone wants to give it a try :-) best regards, Emmanuel. ___ 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 mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Fwd: [osg-users] OSG simplifier question...
or maybe it has something to do with STATIC (DataVariance) objects not being simplified ? -- Forwarded message -- From: Emmanuel Roche [EMAIL PROTECTED] Date: 10 avr. 2007 13:49 Subject: Re: [osg-users] OSG simplifier question... To: osg users osg-users@openscenegraph.net Okay, but, pushing this to an extreme : imagine I have a quad geometry for example, if I use a low enough ratio I shouldn't see anything left, no ? Or can't the simplifier suppress all vertices from a geometry ? Emmanuel 2007/4/10, Robert Osfield [EMAIL PROTECTED]: Hi Emmanuel, The osgUtil::Simplifier can only simplify individual osg::Geometry, it won't group separate geometries together and simplify them as a group. Robert. On 4/10/07, Emmanuel Roche [EMAIL PROTECTED] wrote: Hello there, I'm facing a really strange situation : I've got a model I'm trying to run osgsimplifier on, and apparently I cannot simplify it as much as I want !! I tried every kind of parameters (playing with --ratio and --max-error)... but every time, the model is simplified just a little bit and every attempt to simplify it more give the same result... When I try the same things on the cessna.osg model everything seems to work normaly (using a ratio of 0.01 really crush the polygons as one would except...). So I guess the problem comes from somthing not understood by the simplifier visitor in my model file (can't traverse MatrixTransform ??) ? I'm joining the model if someone wants to give it a try :-) best regards, Emmanuel. ___ 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 mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] How to provide secured access to a SceneGraph in multithread ?
Hi there... I think a lot of people are facing the same problem than me: - My application is multithreaded - I may use multiple 3D windows, with multiple views, based on a single OSG graph (multiple threads accessing the graph to draw) - I have a script thread performing modifications on the graph The only solution I figured out to prevent dead locks until now is to use a BIG mutex to prevent script execution while drawing a frame in a window... but, the performance are very low, so I really need to understand: What's the best solution for multithread access to an OSG graph ??? by the way, aren't visitors supposed to be able to traverse the graph without locking it before ?? regards, Emmanuel. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Error deleting Win32MutexPrivateData in OpenThreadsWin32d.lib
Hello there, I'm trying to build a full debug version of my application, and I'm facing a strange problem : when linking againsthe debug version of OpenThreads on windows, I have an error in the HandleHolder destructor (in handleholder.h) when deleting some OpenThreads::Mutex objects. The problem apparently doesn't happen if I use new/delete instead of objects on the stack, butI cannot use the heap everywhere ! and, in addition, some other objects containing a mutex on the stack lead to the same problem (for example when destroying an osg::Block...) Did anyone already faced this problem ? if yes, how do I solve this ?... regards, Emmanuel ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Fwd: Error deleting Win32MutexPrivateData in OpenThreadsWin32d.lib
hmmm... well, in fact, the same happens with the release version of OpenThreads... I guess I have a big problem somewhere, but I don't see how you could help :-( snif... I starting to hate multithreading... lol Emmanuel. -- Forwarded message -- From: Emmanuel Roche [EMAIL PROTECTED] Date: 4 avr. 2007 14:31 Subject: Error deleting Win32MutexPrivateData in OpenThreadsWin32d.lib To: OSG Users osg-users@openscenegraph.net Hello there, I'm trying to build a full debug version of my application, and I'm facing a strange problem : when linking againsthe debug version of OpenThreads on windows, I have an error in the HandleHolder destructor (in handleholder.h) when deleting some OpenThreads::Mutex objects. The problem apparently doesn't happen if I use new/delete instead of objects on the stack, butI cannot use the heap everywhere ! and, in addition, some other objects containing a mutex on the stack lead to the same problem (for example when destroying an osg::Block...) Did anyone already faced this problem ? if yes, how do I solve this ?... regards, Emmanuel ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Deleting VisualInfo in RenderSurface...
Hello again, I solve the problem for OpenThreads ( simple deletion order question :-) ), but now I'm facing something else : while analyzing my application with a memory analyzing software, I saw that, deleting a RenderSurface object doesn't automatically delete an owned VisualInfo object if any... I looked into the sources, and this object is apparently only really deleted in a private function 'KillGLWindow()'. The only solution I found is something like : delete rs-getVisualInfo(); rs = NULL; (rs being a ref_ptr on a RenderSurface) Isn't there a better solution ? (cleaner I mean...). regards, Emmanuel. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Compiling Samples through Visual Studio 2005
When compiling with Visual Studio 2005, *.manifest files are created for every .dll or .exe file... for some projects, this manifest file is directly embedded in the target file itself (the dll or the exe file), yet, if I remember well, it is the case for OSG... so you should have to put all the *.manifest files next to their corresponding dll or exe... (their is also a tool in MSVC bin directory (mt.exe I think) that you can use to integrate the manifest file in its target...) The runtime error MSVCR80D.dll it most of the time due to not found manifests :-(... that's why I finally went back to MSVC 2003 :-). I hope this will help, Emmanuel 2007/4/3, Harash Sharma [EMAIL PROTECTED]: Dear Robert, I was compiling the Downloaded OSG Source using Visual Studio 2005. All the projects (except 3) compiled successfully. But when I am trying to run some of the examples given, they are giving a runtime error due to non availability of MSVCR80D.dll. The downloaded 3rdParty dependency files do not include this file either. Only MSVCR71.dll and MSVCP80.dll are available. Can you please suggest on the necessary action. Thanks Harash -- Never miss an email again! Yahoo! Toolbarhttp://us.rd.yahoo.com/evt=49938/*http://tools.search.yahoo.com/toolbar/features/mail/alerts you the instant new Mail arrives.Check it out. ___ 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] Audio Integration using osgAL
Hi RJ, If you have some time you may also construct a direct integration of OpenAL in OSG... it's quite easy in fact. (The only complication I faced was to provide plugins to read various form of audio files [but .wav and .ogg are really easy]). I can provide you some sample code if you're interested in this solution. regards, Emmanuel 2007/3/31, Anders Backman [EMAIL PROTECTED]: If you use the svn version of osgAL it should compile just fine with the latest svn version of OpenSceneGraph. Due to some changes in OpenThreads (moving ReentrantMutex from osgDB to OpenThreads) it needs the latest svn version of OT and OSG. Cheers, Anders On 3/31/07, RJ [EMAIL PROTECTED] wrote: Hi Robert, One trouble with osgAL is that it require openal++. But the openal++ sources available on sourceforge are not compiling and the cvs version is not available . So i am stuck with osgAL. Is there any other alternative for integrating audio in OSG. best reagrds RJ On Sat, 2007-03-31 at 11:30 +0100, Robert Osfield wrote: Hi RJ, On 3/31/07, RJ [EMAIL PROTECTED] wrote: Hi Guys, I want to integrate 5.1 stereo audio in my project. Any Suggestions? best regards and thanks in advance Would OpenAL suffice? If so there is an osgAL NodeKit available, check the community section for it. Robert. ___ 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/ -- 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/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] virtual texture ? mega texture ? something else ?
Hello everyone, Currently, I'm developing a program where I have to display an Earth model... to perform this I use : - a big sphere shape... - a dds texture of 4096x2048 for day time - another similar texture of 4096x2048 for night time - a cloud texture of ... 4096x2048 :-( - another normal map .png texture of 4096x2048 again... - a shader to mix all this... ... as you might guess, I need something like a geforce 7900 to run this... but now I would like to port this simulation on low computer, my question is simple: how can I do this without loosing texture quality ??? In fact, my question is more general: taking into account that using big textures is bad (I read somewhere that 512x512 is the better choice to keep things real time...), is there any solution right now to cut objects and textures to tile them in OSG ?? i'm aware about the LODing system for terrain shapes, but I'm speak about more general shapes, and i'm not wanting to store too huge databases. I tried the OSSIM library lately, with their ossimPlanetViewer, that a good example of dynamic tile generation, another good example of what i'm looking for is the Celestia Virtual texture concept... the key is : getting the big textures, and use them directly (the software taking care of cutting them and cutting the models of example... [that's the only pratical solution I see to display more information])... is there any library or add on trying to provide this in OSG ? regards, Emmanuel ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] virtual texture ? mega texture ? something else ?
No osgdem would not be enough : some of the textures I use can change dynamically, how could I use them on osgdem tiles, the uv coords would hardly correspond, no ? regards, Emmanuel. 2007/3/28, Serge Lages [EMAIL PROTECTED]: On 3/28/07, Emmanuel Roche [EMAIL PROTECTED] wrote: Hello everyone, Currently, I'm developing a program where I have to display an Earth model... to perform this I use : - a big sphere shape... - a dds texture of 4096x2048 for day time - another similar texture of 4096x2048 for night time - a cloud texture of ... 4096x2048 :-( - another normal map .png texture of 4096x2048 again... - a shader to mix all this... ... as you might guess, I need something like a geforce 7900 to run this... but now I would like to port this simulation on low computer, my question is simple: how can I do this without loosing texture quality ??? In fact, my question is more general: taking into account that using big textures is bad (I read somewhere that 512x512 is the better choice to keep things real time...), is there any solution right now to cut objects and textures to tile them in OSG ?? i'm aware about the LODing system for terrain shapes, but I'm speak about more general shapes, and i'm not wanting to store too huge databases. I tried the OSSIM library lately, with their ossimPlanetViewer, that a good example of dynamic tile generation, another good example of what i'm looking for is the Celestia Virtual texture concept... the key is : getting the big textures, and use them directly (the software taking care of cutting them and cutting the models of example... [that's the only pratical solution I see to display more information])... is there any library or add on trying to provide this in OSG ? regards, Hi ! Have a look at osgdem (or VirtualPlanetBuilder in the svn), it provides what you need to tile your terrain. -- 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/
[osg-users] osgDB DataFilePathList for non standard file extensions
Hello everyone, I'm using a plugin to read OSG nodes in .gz files I developed on my own. It works perfectly well, but now I would like to use this plugin with the DataFilePathList handling system in osgDB and I can't get it working this way... I tried something like: osgDB::FilePathList pathList = osgDB::getDataFilePathList(); pathList.push_back(X:\\Work\\4DV\\SESSEngine\\Projects\\Sat\\Models\\); osgDB::setDataFilePathList(pathList); then : node = osgDB::readNodeFile(ISS.gz) // NOT WORKING node = osgDB::readNodeFile(ISS.ive) // WORKING ... both files are in the concerned directory of course... ... Did I missed something to register the new file extension ??? regards, Emmanuel. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] osgDB DataFilePathList for non standard file extensions
Great ! Indeed, this solve the problem. thanks ! Emmanuel. 2007/3/27, Robert Osfield [EMAIL PROTECTED]: Hi Emmanuel, osgDB leaves the finding of files up to the plugins themselves, this way they can decide whether the filename is a file at all (for instance a psuedo loader) or use standard or custom file path determination. In most plugins you'll find lines like the following: std::string fileName = osgDB::findDataFile( file, opt ); if (fileName.empty()) return ReadResult::FILE_NOT_FOUND; Its the findDataFile that does the checking at the DataFilePathList. Robert. On 3/27/07, Emmanuel Roche [EMAIL PROTECTED] wrote: Hello everyone, I'm using a plugin to read OSG nodes in .gz files I developed on my own. It works perfectly well, but now I would like to use this plugin with the DataFilePathList handling system in osgDB and I can't get it working this way... I tried something like: osgDB::FilePathList pathList = osgDB::getDataFilePathList(); pathList.push_back (X:\\Work\\4DV\\SESSEngine\\Projects\\Sat\\Models\\); osgDB::setDataFilePathList(pathList); then : node = osgDB::readNodeFile(ISS.gz) // NOT WORKING node = osgDB::readNodeFile(ISS.ive) // WORKING ... both files are in the concerned directory of course... ... Did I missed something to register the new file extension ??? regards, Emmanuel. ___ 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 mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] osgDB DataFilePathList for non standard file extensions
Well that's simple Paul: the DataFilePaths object is a std:deque... so you can use push_front() and push_back(): osgDB:getDataFilePathList().push_front(C:/My/path/to/check/first) or osgDB:getDataFilePathList().push_back(C:/My/path/to/check/last) regards, Emmanuel. 2007/3/27, Paul Martz [EMAIL PROTECTED]: On a related note, setDataFilePathList() clears out the current path list. So, if an app calls this function, it essentially overrides any setting of OSG_FILE_PATH, correct? I poked around in osgDB and couldn't find an obvious way for an application to simply append one or two paths to the file path list (as opposed to completely overriding the path list). How would an application do this? -Paul -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Emmanuel Roche *Sent:* Tuesday, March 27, 2007 3:53 AM *To:* OSG Users *Subject:* [osg-users] osgDB DataFilePathList for non standard file extensions Hello everyone, I'm using a plugin to read OSG nodes in .gz files I developed on my own. It works perfectly well, but now I would like to use this plugin with the DataFilePathList handling system in osgDB and I can't get it working this way... I tried something like: osgDB::FilePathList pathList = osgDB::getDataFilePathList(); pathList.push_back(X:\\Work\\4DV\\SESSEngine\\Projects\\Sat\\Models\\); osgDB::setDataFilePathList(pathList); then : node = osgDB::readNodeFile(ISS.gz) // NOT WORKING node = osgDB::readNodeFile(ISS.ive) // WORKING ... both files are in the concerned directory of course... ... Did I missed something to register the new file extension ??? regards, Emmanuel. ___ 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/
