Re: [osg-users] osgHUD 0.1.4 (testing)
On Fri, 2008-01-25 at 10:17 -0500, Jean-Sebastien Guay wrote: Hi Jeremy, Here are some screenshots, Wow, very nice! The potential for this is endless! How is performance compared to just a normal texture that you would map onto a quad? Well, the way it current works is that the image (osgCairo::SurfaceImage, which is derived from both osg::Image and the Cairo surface type) renders to a memory buffer (which is provided by osg::Image, so wherever it actually stores the data...?) and then you call -dirty() on the image and apply it to a quad. You can do this as often as you like to update the texture. In terms of performance, Cairo itself makes every attempt to be as fast as possible, and provides multiple surfaces types for us to use. I use the memory buffer surface, since it maps so well to the memory osg::Image provides, but there are also PDF, PS, and SVG surfaces. There is also an OpenGL accelerated surface type called Glitz, but it's CVS hasn't been updated in a year and I have the hardest time getting it to play nice with other OpenGL apps. Thus, I opted to go with the software Cairo rendering surface, but as long as you aren't redrawing a surface every frame, you should be fine. In fact, my intentions really are to make it so that all images are generated once at load time, so that they are only ever drawn once in the lifetime of the program. Conceptually it would be no different than actually loading the images from files, save that you could define various criteria that control at what resolution the images are rendered for maximum awesomeness. :) I hope to be able to test this on Windows soon and give you some feedback on that front. J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgHUD 0.1.4 (testing)
On Fri, 2008-01-25 at 09:30 -0500, Lucas Goss wrote: Sweet! I see the movies are in wmv... eww, haha. That may help Windows users but then Linux and Mac users can't watch them (without finding codecs). A standard video format would be nicer... Trust me, I tried, but I was unable to find a tool in Linux that would encode a video that would work easily on both operating systems. No matter what I did with ffmpeg (or anything else that might use the same libraries it does), I couldn't get one. If you know the invocation, please by all means tell me. :) But anyways, I found some more issues when building. If I try to build with Lua I get compiler errors that it can't find lua.h. On my ubuntu machine, I have Lua 5.0 installed, and apparently it has a separate directory (lua50)... and so does Lua 5.1 (lua5.1)... so the current package lookup for lua doesn't work. And I don't get the option to set my own path to Lua if it's not found. I'm not a CMake wiz either so I hunted down some FindLua cmake files here: http://trac-hg.assembla.com/CMakeLua/browser/Modules?rev=109%3Adabdf86e8763 Well, nothing fancy should really be required if pkg-config is properly reporting values. I'm using Fedora these days and the FindPkgConfig module for CMake should take care of that. However, I'll grab an Ubuntu machine here in the office later today and test this out more--thanks for the heads up. So I changed my local CMake to pick up the lua50 package, and I get another error that luaL_openlibs could not be found. I think that is a lua 5.1 call? So back to CMake, haha. So maybe a note that lua requires lua 5.1... and it's all compiling now (had to change the package from lua to lua5.1). Yeah, Lua 5.1 is definitely required, so I'll make a note of that. :) Lucas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.3.4 dev and VirtualPlanetBuilder-0.9.5 dev releases tagged.
On Tue, 2008-01-29 at 21:34 +, Robert Osfield wrote: Hi All, I've just tagged the OpenSceneGraph-2.3.4 and VirtualPlanetBuilder-0.9.5 developer releases. OSG-2.3.4 Details on: http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases VPB-0.9.5 Details on: http://www.openscenegraph.org/projects/VirtualPlanetBuilder On my return in mid February we can start looking at converging things towards OSG-2.4 and VPB-1.0. Have fun while I'm away, if not possible I'll have fun on your behalf ;-) Robert. Is it even possible to take a vacation when you live in Scotland? Isn't every day a holiday when everything around is green and coastal? :) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with shaders in osg on geforce 7800
On Thu, 2008-01-31 at 08:44 -0500, Jean-Sébastien Guay wrote:
Hello Roni,
I don't have an error message, and the image is not black, I just get
the same picture I would get without running shaders.
You say you don't get any error messages, but did you set
OSG_NOTIFY_LEVEL=DEBUG when running your app? Any GLSL compiler
warnings/errors will show up then.
As a side note, I wonder if Robert could be convinced to remove these
messages:
cull_draw() 0x805a808
end cull_draw() 0x805a808
...from DEBUG or INFO level output, as I get about 6 zillion of them
every second, making setting the notify level pretty useless. Am I the
only one that sees this?
In my experience, the GLSL compilers are pretty picky, and even warnings
will force the pipeline back to fixed-function, which is what you're
seeing. So check that.
Any ideas? Maybe a driver issue? Maybe the card doesn't support the
shaders used in osg 2.2?
Apart from the above, a driver issue is always possible (if it's a new
machine, the first thing you should do is update your video card drivers!).
A GeForce 7800 is by no means old, so most shaders should work fine on
it. I have a 7900 at home and it works fine. The things that are
supported by the 8800 and not by the 7900 are (in a nutshell) Shader
Model 4 and Geometry Shaders, but I doubt your trivial
gl_FragColor=vec4(1,0,0,1) shader uses any of that! :-)
One thing I have sometimes seen is the shader being replaced by an empty
osg::Program lower down in the scene graph. The empty osg::Program will
effectively disable shaders and the subgraph will thus be rendered by
the fixed pipeline. One way to see if that's happening is to output your
scene graph to an .osg file and inspect it in a text editor.
#include osgDB/WriteFile
int main(int argc, char** argv)
{
osg::ref_ptrosg::Group root = new osg::Group;
//... build scene graph ...
osgDB::writeNodeFile(*root, output.osg);
// Make sure the write is the last thing you do before running the
viewer, so
// you're pretty sure you're writing the final scene graph to the file.
viewer.setSceneData(root.get());
return viewer.run();
}
Good luck,
J-S
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with shaders in osg on geforce 7800
On Thu, 2008-01-31 at 13:41 -0600, Thrall, Bryan wrote: Jean-Sébastien Guay wrote on Thursday, January 31, 2008 1:23 PM: Hello Bryan, You could move them to notify level DEBUG_FP; DEBUG uses DEBUG_INFO, so they would then be left out of any but the most verbose output. I'll submit a change to this effect. Jeremy already submitted a change to remove the messages completely... Since no change will be checked in until Robert comes back, I suggest you hold back, see if he'll agree with removing the messages, and if not then you can submit a change to move them to DEBUG_FP. Thanks, J-S Too late, now, we have dueling patches :P I hope you brought your Vorpal Sword... or your patch will get sent galumphing back! :) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems with picking and HUDs
On Mon, 2008-02-04 at 17:15 +0100, Pedro José Muñoz wrote: Hi all, Making an application to show the name of different elements, I can do it with everything except with HUDs, do you have any idea why does it happen? This is going to depend a lot on how you create your HUD. Without more information, no one could possibly help. :) Thanks in advance ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] making a movie of an OSG simulation
On Wed, 2008-02-06 at 16:16 +, Pete Carss wrote: Yukon does the same as fraps on Linux... Bugle, too. However, I used to help the Yukon guys, and I'm glad they're still up and running. I'd highly recommend both of these on Linux. I used Bugle to make the osgWidget videos, btw... Pete Sebastian Messerschmidt wrote: IIRC a little tool called fraps is doing the job. cheers psy hi I wanted to make a movie of whatever is displayed on the screen when running an osg program. how do i do it ? Thank You ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: osgPython (SWIG) 2.2.0
Just as a head up, it doesn't look like the project was created using the standard trunk/tags/branches layout, so the link that the Google Source tab provides is wrong... On Tue, 2008-02-12 at 19:07 +0100, René Molenaar wrote: Swig wrappers for OpenSceneGraph Python and Perl These files are part of: The VRmeer Library - Delft University of Technology The files are based on osgswig (http://code.google.com/p/osgswig/) with some additions and CMake files. (I currenlty use swigwin 1.3.29 and the current svn trunk of osg but other platform and versions are also being used. There is only one example, all our other examples make heavy use of The VRmeer Library and the vrmswig library.) You can also just copy the needed cmake files and place them in the right directories of the online version. To use cmake to build your project. Good Luck. Rene Molenaar 2008/2/12, Luigi Calori [EMAIL PROTECTED]: I would also be interested in Cmake osgswig building I, as a novice in both python and Lua, would greatly appreciate any script example usage. I' m trying to use the binary version of osgSwig, it seems working well but some further python example would really help Is this the right place to ask question regarding osgswig? thanks in advance and compliments for the work Luigi René Molenaar wrote: I just separated an osgswig cmake project from our larger Library. Tomorrow I can try to build some of your version of the wrappers in this structure. (our version has changed a version of yours here and there). You can add me to the Project members of the google code page? I saw another member on there, I worked with him to create our current version. He makes great use of osgPython in combination with IPython gtk and the rest of our Library. Cheers, René 2008/2/12, Hartmut Seichter [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hi there, I updated the SWIG based python bindings. http://code.google.com/p/osgswig/ Please test and break it. Some, hopefully, clarifying words about licensing: The generating scripts are under the MIT license. The modules directly derived from OpenSceneGraph are following the OSGPL v0.0 or the appropriate licenses. The HITLabNZ (http://www.hitlabnz.org) is promoting the GPL version of osgART 1.1, ARToolKit for OpenSceneGraph, with this release. If you are using this module you also agree to follow the licensing terms of the GPLv2. Shameless plug :) If you need a commercial license for osgART or features beyond marker based tracking please contact ARToolworks Inc. (http://www.artoolworks.com/) Cheers, Hartmut ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ANN: osgWidget 0.1.5
Finally got around to a point where I feel somewhat comfortable with another alpha release (after renaming the project to osgWidget from osgHUD). No major changes from a visual standpoint, but lots has changed internally. For example, picking has been significantly changed and I added the ability to assign either function callbacks or class-method callbacks to a Widget or Window, along with maintaining the ability to simply override mouseOver, mouseDrag, etc. in a derived class. I also added Lua and Python engine skeletons in this, though they don't do anything interesting yet. However, ideally, if all goes according to plan, you will be able to use either (or both!) scripting engines for interfacing with osgWidget. The reason I chose to use both instead of just Python (since I really don't have any love for Lua) is because Python doesn't provide any way to lock itself down, and if a user requires this Lua would be more appropriate (think games, like World of Warcraft, where you want to create a modding API but want to restrict the environment to prevent cheating, etc.) As much as I love Python, it has no solution to this problem at the moment... CHANGELOG here: http://code.google.com/p/osgwidget/source/browse/tags/0.1.5/CHANGELOG PROJECT here: http://osgwidget.googlecode.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Back from holidays...
On Thu, 2008-02-14 at 14:35 +, Robert Osfield wrote: Hi All, I'm now back from my trip to the Cayman Islands, much sailing, snorkeling and family time was enjoyed. 16 days without touching a computer is the longest I've gone for 9 years, and not a single withdraw symptom, just had too fund stuff to distract me :-) You'll be seeing a scattering of emails from me today as I slowly make my way through my email backlog. I'm a bit jet lagged am not fully functioning so if I write more nonsense than I usually do then put it down to 5 hour shift in time of day... Woot, good times. :) It's been 16 days, wow... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Copy Constructor Advice
I have a quick question that I may be over-thinking, of which I have yet
to find a simple answer.
Imagine that I have a class Derived from osg::MatrixTransform--let's
call this osgWidget::Window. In my derived Window class, I have a number
of osg::ref_ptr objects referencing various things that get added to
the Window object itself, and which I keep around for ease of use
elsewhere in the API.
I want to provide suitable copy constructors (and am required to do so
by using the META_Object macro, thankfully), but I'm beginning to see a
definite problem when setting the pointers in the new copies ref_ptr
object. Usually I can come up with clever tricks to do so, but generally
it's not very straightforward--which leads me to my main question: is it
generally bad design to keep ref_ptr's around like this when designing
classes that will directly derive from OSG objects? Using
osg::CopyOp::DEEP_COPY_ALL ensures that I will get a full copy of the
subgraph, which is certainly the desired behavior, but I'm not entirely
sure I know the best way to easily set any internal ref_ptr's to the new
subgraph after copy other than--like I mentioned earlier--clever
tricks. :) Below is an example of one such abomination:
// Here we're in the copy ctor()
Window::Window(const Window w, const CopyOp co):
MatrixTransform(w, co) {
ColorArray* c = dynamic_castColorArray*(getColorArray());
if(c) _c = c;
}
...where _c is my osg::ref_ptrColorArray object, and where
getColorArray() works because we're using DEEP_COPY_ALL and we assume
all of the geometry was deeply copied into the new object.
I really feel like I'm missing an easier way to do this...
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Copy Constructor Advice
On Tue, 2008-02-19 at 09:44 +, Robert Osfield wrote:
Hi Jeremy,
In your case where you have data being shared between a subclass and
its base class I feel that this duplication of ref_ptr to the shared
data is inappropriate. Rather what you should use in your own code is
dynamic_castVec3Array* where you need access to the array, or to
provide a convenience method to getVec3Array() { return
dynamic_castVec3Array*(getVertexArray()); }
Yeah, you're right about this; the duplication probably is
inappropriate, and is exemplified by issues here with it. :)
Would this solve this problem?
Yes indeed! I will make it so...
Robert.
On Feb 18, 2008 7:31 PM, Jeremy Moles [EMAIL PROTECTED] wrote:
Thanks for the response, Robert.
On Mon, 2008-02-18 at 17:54 +, Robert Osfield wrote:
Hi Jeremy,
Most OSG objects implement the clone operator with CopyOp parameter so
you can just pass this along. For objects like std::vector etc you
would typically just implement a deep copy, i.e. copy all the
contents, unless of course its a vector of ref_ptr's in which case
copying the contents of the vector shares the pointers so you have to
do a element by element deep copy op on the objects if that's what is
required.
To see examples of various ways of implementing the copy operator have
a look at the implementations - they are all over the OSG.
Hmm, I think I probably wasn't as clear as I could have been--or perhaps
I'm still misunderstanding. Let me provide another very simple,
contrived example here:
// ---
struct MyGeometry: public Geometry {
ref_ptrVec3Array _verts;
MyGeometry() {
_verts = allocateSomeGeometry();
setVertexArray(_verts.get());
}
MyGeometry(const MyGeometry myG, const CopyOp co):
Geometry(myG, co) {
}
}
MyGeometry* mg1 = new MyGeometry();
MyGeometry* mg2 = mg1-clone(CopyOp::DEEP_COPY_ALL);
// ---
With the above code, the _verts ref_ptr in mg2 won't point to anything,
since I haven't intialized it, although mg2 WILL have the proper
geometry, since there was a deep copy of all the existing data (in fact,
osgWidget introduces it's own cloneAs method which always does a
DEEP_COPY, since this is almost always desired). What I'm wanting to
do--and haven't been able to find an example of in OSG yet--is an easy
way to set _verts in the copy. Simply adjusting the copy constructor to
look like the following:
// ---
MyGeometry(const MyGeometry myG, const CopyOp co):
Geometry (myG, co),
_verts (myG._verts) {
}
// ---
...gives me a ref_ptr that references data in the old object, naturally.
Currently, I'm able to work around and get the desired behavior, but I
want to make sure everything is proper before implementing a lot of
stuff wrong and having the submission rejected because of little weird
things like this. :)
You can see a real world example in action here:
http://code.google.com/p/osgwidget/source/browse/tags/0.1.5/src/Widget.cpp#70
Robert.
On Feb 18, 2008 5:10 PM, Jeremy Moles [EMAIL PROTECTED] wrote:
I have a quick question that I may be over-thinking, of which I have yet
to find a simple answer.
Imagine that I have a class Derived from osg::MatrixTransform--let's
call this osgWidget::Window. In my derived Window class, I have a number
of osg::ref_ptr objects referencing various things that get added to
the Window object itself, and which I keep around for ease of use
elsewhere in the API.
I want to provide suitable copy constructors (and am required to do so
by using the META_Object macro, thankfully), but I'm beginning to see a
definite problem when setting the pointers in the new copies ref_ptr
object. Usually I can come up with clever tricks to do so, but generally
it's not very straightforward--which leads me to my main question: is it
generally bad design to keep ref_ptr's around like this when designing
classes that will directly derive from OSG objects? Using
osg::CopyOp::DEEP_COPY_ALL ensures that I will get a full copy of the
subgraph, which is certainly the desired behavior, but I'm not entirely
sure I know the best way to easily set any internal ref_ptr's to the new
subgraph after copy other than--like I mentioned earlier--clever
tricks. :) Below is an example of one such abomination:
// Here we're in the copy ctor()
Window::Window(const Window w, const CopyOp co):
MatrixTransform(w, co) {
ColorArray* c = dynamic_castColorArray*(getColorArray());
if(c) _c = c
Re: [osg-users] converting .svg to .osg?
On Tue, 2008-02-19 at 14:18 -0600, Mike Weiblen wrote: Hi, What is the easiest path getting a .svg file into OSG, for conversion to .osg format? Oh! Oh! Oh! Add support for that to osgCairo! :) I've been meaning to do it forever, but just haven't had time... this would be an awesome feature. Otherwise, ummm, I'm not sure... It's only available in SVN right now, as I plan to jump on it later in full force when I finish osgWidget. http://osgcairo.googlecode.com If it was anyone else I wouldn't even bring this up, but I know you're heavily involved in OSG stuff and aren't opposed to hacking if necessary. :) Thanks -- mew ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] converting .svg to .osg?
On Tue, 2008-02-19 at 16:15 -0600, Mike Weiblen wrote: Just looking for a quick conversion of .svg vector art (specifically the ISO 12233 test chart at http://www.graphics.cornell.edu/~westin/misc/res-chart.html) into OSG/OpenGL verts/geometry in a .osg file. No imagery or prerasterization; that would defeat the value of the test chart geometry. Yeah, could do it by hand/script, but I think I'll tinker w/ the osgCairo approach, unless someone already as an OSG-loadable version of Do it! :) 3 If you have a googlecode account, I can give you SVN access. With enough refinement, I bet Robert would allow this is OSG... that 12233 chart? ;-) Cheers -- mew -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Somerville, Andrew Sent: Tuesday, February 19, 2008 3:11 PM To: OpenSceneGraph Users Subject: RE: [osg-users] converting .svg to .osg? I wrote a quick an dirty osg svg plugin for using an svg file into a texture using librsvg, but thats probably not what you are looking for; I'm not really clear what you mean by converting to .osg format. In any case its available for anyone interested. Andy -Original Message- From: [EMAIL PROTECTED] on behalf of Mike Weiblen Sent: Tue 2/19/2008 3:18 PM To: OpenSceneGraph Users Subject: [osg-users] converting .svg to .osg? Hi, What is the easiest path getting a .svg file into OSG, for conversion to .osg format? Thanks -- mew ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] converting .svg to .osg? ... or project from svg to svg
I'm working on creating a quick, simple example of taking a Cairo context (which could many things, but just think a vector graphic for our purposes) and creating 3D geometry for it, just like 3D Text. When I'm done, I'll put this in osgCairo, and hopefully generate a bit more interest. On Wed, 2008-02-20 at 11:10 -0600, Mike Weiblen wrote: Indeed, I envision an .svg-.osg path to be bidirectional. -- mew -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Per Rosengren Sent: Wednesday, February 20, 2008 1:43 AM To: OpenSceneGraph Users Subject: Re: [osg-users] converting .svg to .osg? ... or project from svg to svg I have used 3dldf (http://www.gnu.org/software/3dldf/) earlier to create vector graphics from 3d models. It would be extremely cool to extend osg to create vector graphics output with an SVG Viewer! Imagine infinite resolution rendering! This would be really difficult, since you can't use depth buffer or ray tracing techniques. Jeremy Moles wrote: On Tue, 2008-02-19 at 16:15 -0600, Mike Weiblen wrote: Just looking for a quick conversion of .svg vector art (specifically the ISO 12233 test chart at http://www.graphics.cornell.edu/~westin/misc/res-chart.html) into OSG/OpenGL verts/geometry in a .osg file. No imagery or prerasterization; that would defeat the value of the test chart geometry. Yeah, could do it by hand/script, but I think I'll tinker w/ the osgCairo approach, unless someone already as an OSG-loadable version of Do it! :) 3 If you have a googlecode account, I can give you SVN access. With enough refinement, I bet Robert would allow this is OSG... that 12233 chart? ;-) Cheers -- mew -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Somerville, Andrew Sent: Tuesday, February 19, 2008 3:11 PM To: OpenSceneGraph Users Subject: RE: [osg-users] converting .svg to .osg? I wrote a quick an dirty osg svg plugin for using an svg file into a texture using librsvg, but thats probably not what you are looking for; I'm not really clear what you mean by converting to .osg format. In any case its available for anyone interested. Andy -Original Message- From: [EMAIL PROTECTED] on behalf of Mike Weiblen Sent: Tue 2/19/2008 3:18 PM To: OpenSceneGraph Users Subject: [osg-users] converting .svg to .osg? Hi, What is the easiest path getting a .svg file into OSG, for conversion to .osg format? Thanks -- mew ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] MouseCoords - TexCoords
I would like to provide a user of osgWidget with the ability to get the color value of any textured Widget, particularly whatever 2D coord the mouse is currently over. I've played with a number of implementations for doing this, but I wanted to get some opinions on what the BEST way to do it is. (Also: this is just for osg::Texture2D at the moment) When I want to calculate the color value I have access to the following information: - The GLOBAL mouse coords - The LOCAL mouse coords (relative to the Widget itself) - The tex coords of all 4 points of the quad (Widget) - The dimensions of the Widget (width, height, etc.) In the simplest case, assuming the quad is fully mapped by the texture, I can do something like the following: x = LocalMouseX / WidgetWidth y = LocalMouseY / WidgetHeight ...which, easily enough, will also give me the tex coord that I can pass to osg::Image::getColor(). However, things become more complicated when you only use a portion of the Image in your Widget's tex coord mapping, and I've come up alternative ways of handling those scenarios, none of which feel very clean or proper. Is there an arbitrary way to translate mouse coordinates (given the data I have access to) into texture coordinates? I don't need the code to do this, just some ideas to push me in the right direction... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Example code: Using CompositeViewer to visualize theview frustum
This is a really cool example. :) Is there any way an option could be added so that the 3rd person view is rendered on top of the regular view (eliminating the need for 2 windows?) This would be informative when someone wants to create a rear-view mirror display or something. Or, does CompositeViewer not support this? (I imagine that's certainly possible...) On Wed, 2008-02-27 at 14:57 -0700, Paul Martz wrote: I cleaned this up a bit and posted it to osg-submissions as osgthirdpersonview. -Paul __ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Wednesday, February 27, 2008 12:13 PM To: 'OpenSceneGraph Users' Subject: [osg-users] Example code: Using CompositeViewer to visualize theview frustum Hi folks -- I recently created the attached example program to visualize the camera position, orientation, and view volume. I thought others might find it interesting so I wanted to post it. If I get some positive feedback, I'll try to pretty it up and submit it as an OSG example. As you can see from the attached screen shot, the code opens two windows. In one, you see a normal view, and in the other, you get a third person view showing the view volume, which updates as you manipulate the first view. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Vector class Hacks?
On Thu, 2008-02-28 at 09:11 +, Robert Osfield wrote: On Wed, Feb 27, 2008 at 10:06 PM, Night Hawk [EMAIL PROTECTED] wrote: Surprising indeed. I was about to override the Array classes to use native c-style arrays. But now it seems OSG can convert vectors to C-style arrays fast enough :) The OSG wouldn't do it if it wasn't efficient, its literally a non op, a std::vectorVec3 is implemented as Vec3* array on almost all STL implementations, although technically it might not be. All platforms/compilers that the OSG works with implement a std::vectorVec3 as a Vec3* array. Wish the documentation (either for vector or for OSG) can cover this. People like me who have seen NO STL for gaming slogans are taken aback when we see OSG using STL heavily. I suspect STL got a bad name due to VS 6.0's appalling STL implementation, and few out spoken and mis informed fanatics would advocated inventing everything yourself, seemingly based on the principle that games programmers could master all spheres of programming better than anyone else. I vote the above paragraph for quote of the week. The OSG uses STL because its: fast maximizes code reuse maximizes skills reuse minimizes the amount of code we have to develop, optimize, test, debug and document due to minimizing wasted time, it maximizes time we can spend on effective software develop i.e. the scene graph rather than the C++ infrastructure For a C++ app, STL just makes so much sense that one would be a bit deluded to not want to leverage the great work of others, STL is truely a great work of modern software engineering ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] animtk
On Fri, 2008-02-29 at 15:36 +0100, Cedric Pinson wrote: Hello, Animtk is an animation library toolkit. it's a very soon project and not really mature yet. i 'release' a version with an openscenegraph example. i would like to have feedback from people. So if you have time to test it quickly, i will appreciate feedback. The project is on gnu/linux right now and there is no project for visual studio. there is page with some explanation http://animtk.plopbyte.net/ and to get the source http://download.gna.org/animtk/animtk-0.0.6.tar.gz if you are interested to get the last source hg clone http://hg.plopbyte.net/animtk Thank you Quoted from the website: Animtk is a general lib written in c++ to animate different kind of data. It uses template to add new data type to animate. Does this mean you can inject OSG data type into the library, so that you don't have Vector/Matrix/Quat duplication? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] animation synchronisation
There's this: http://animtk.plopbyte.net/ ...which I think more OSG people should take a look at; all of these examples use OSG, and it seems like it could be a decent enough NodeKit (though I'm no expert in the subject matter). It still needs some cleanup in the project directory, needs to be made to use CMake, etc.--but perhaps I could take an hour or so myself and do this. At any rate, once I get to the animation needs for own hobby projects, this is what I'll be using. In fact, it seems to have really grown since we had that character animation discussion a few months back before 2.2 was released... On Sun, 2008-03-02 at 21:51 +0100, [EMAIL PROTECTED] wrote: Hello! How can/should I synchronize the application flow-control to the end of an animation (realized as osg::AnimationPath) ? Assume: we have a projectile that should be animated. 1. we calculate the trajectory and setup the animation-path with some trajectory data. 2. then the animation-path will be applied to the projectile-node (the exact way to do this, is still vague to me; the only information source I found untill now, is the osganimation example, which handles only a single animation type, with endless animation) 3. == now: how can I sync the rest of the application with the end of the projectile-animation ? == e.g. expand scene graph with new data, start other animation(s), etc... The way with polling the timer seems somehow crude to me... There should be a better way ?! (better documentation !) Thanks, Alexej ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Sheep++
I have no idea where this came from, someone just AIM'd it to me at work--and it's freaking awesome: A programmer started to cuss, Because getting to sleep was a fuss. as he lay there in bed... looping round in his head... Was: while(!asleep()) sheep++; ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Font Quality / osgWidget
I've attached a screenshot of some text rendered in a very standard way using osgText: text-setFont(std::string(fonts/monospace.ttf)); text-setCharacterSize(size); text-setFontResolution(size, size); text-setText(label); text-setColor(osg::Vec4(1.0f, 1.0f, 1.0f, 1.0f)); In the screenshot, a the very bottom, you'll see a bit of text called label 6 (copy). Take a close look at the following characters: a, e, 6, ( ...and you'll notice that the glyphs are 1 (perhaps 2) pixels chopped off at the left. I've been hunting this down forever--in fact, I've made a lot of similar posts in the past--but I simply cannot prevent this occurrence in a predictable way. If I play with the font sizes I can sometimes achieve nearly perfect font quality, but it's all guess-work. So I've decided to go back to square one and ask the mailing lists: can anyone with any heavy osgText experience give me any hints as to what is going on? I've tried all of the KERNING options (though this is a monospace font), I've tried hacking Text/TextBase.cpp so that each Glyph absolutely is pixel aligned, I've tried all manner of different fonts--but nothing seems to give predictable rendering results. My suspicion is that the GlyphQuads object's _texcoords values are getting calculated slightly wrong in some cases, but I'm not sure. Having precise font quality in osgWidget will be really important, so I'm willing to make any code changes necessary to facilitate this... attachment: orig.png___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Font Quality / osgWidget
I'd like to add another bit of info to this thread; attached are two screenshots (good.png bad.png) rendered using almost identical code: good.png (sharp, crisp) text-setFontResolution(...) text-setCharacterSize(...) text-setText(...) bad.png (very blurry) text-setText(...) text-setFontResolution(...) text-setCharacterSize(...) text-update() Is there something wrong with my 2nd usage of osgText::Text such that I get the poorer quality? I understand that in the first usage the font sizes are already set before the initial text is rendered internally, but shouldn't the 2nd usage produce identical results, given that I call update after setting the new values? (My assumption here, however, could be woefully wrong, but will be useful information either way. :)) On Wed, 2008-03-05 at 16:10 -0500, Jeremy Moles wrote: I've attached a screenshot of some text rendered in a very standard way using osgText: text-setFont(std::string(fonts/monospace.ttf)); text-setCharacterSize(size); text-setFontResolution(size, size); text-setText(label); text-setColor(osg::Vec4(1.0f, 1.0f, 1.0f, 1.0f)); In the screenshot, a the very bottom, you'll see a bit of text called label 6 (copy). Take a close look at the following characters: a, e, 6, ( ...and you'll notice that the glyphs are 1 (perhaps 2) pixels chopped off at the left. I've been hunting this down forever--in fact, I've made a lot of similar posts in the past--but I simply cannot prevent this occurrence in a predictable way. If I play with the font sizes I can sometimes achieve nearly perfect font quality, but it's all guess-work. So I've decided to go back to square one and ask the mailing lists: can anyone with any heavy osgText experience give me any hints as to what is going on? I've tried all of the KERNING options (though this is a monospace font), I've tried hacking Text/TextBase.cpp so that each Glyph absolutely is pixel aligned, I've tried all manner of different fonts--but nothing seems to give predictable rendering results. My suspicion is that the GlyphQuads object's _texcoords values are getting calculated slightly wrong in some cases, but I'm not sure. Having precise font quality in osgWidget will be really important, so I'm willing to make any code changes necessary to facilitate this... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org attachment: bad.pngattachment: good.png___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Font Quality / osgWidget
Great info!
Is there any way we can get this modification as an attachment, and not
inline? The likelihood of Robert looking at it seriously is very low if
it's not easily detachable from the e-mail. :)
But again, this is great, great info! Thanks a ton!
On Thu, 2008-03-06 at 10:09 -0800, Mark Sciabica wrote:
I ran into the same problem and I agree that the appearance of the
clipped text is quite ugly. Unfortunately, the problem lies within the
design of osgText and not your usage of it.
Texels sampled within the character cell are linearly blended with one
another, giving an antialiasing effect internal to the character cell.
However, when a character cell has a texel set at its edge, no
blending takes place outside that edge because the texture isn't drawn
outside the quad.
My solution was to modify osgText to draw larger quads for the
character cells (by one texel in each direction), adjusting texture
coordinates accordingly. Side effects are that character cells now
overlap so depth testing needs to be disabled (or some sort of
stenciling operation performed), and extra margin should be allocated
for each character in the texture (using Font::setGlyphImageMargin).
Another possible solution is to disable texture filtering, so all
parts of each character will have the same clipped appearance. If
you're already using some sort of full screen antialiasing this might
not look too bad.
Below is my modified version of Text::computeGlyphRepresentation()
from osgText/Text.cpp. The modified code is controlled by #ifdefs.
Robert: Given the restrictions (depth writing needs to be disabled),
is this something you would want to add to osg? Perhaps configurable
as an optional method of text rendering? If so, I'll submit the
changed files to the submissions list.
void Text::computeGlyphRepresentation()
{
Font* activefont = getActiveFont();
if (!activefont) return;
_textureGlyphQuadMap.clear();
_lineCount = 0;
if (_text.empty())
{
_textBB.set(0,0,0,0,0,0);//no size text
computePositions(); //to reset the origin
return;
}
OpenThreads::ScopedLockFont::FontMutex
lock(*(Font::getSerializeFontCallsMutex()));
// initialize bounding box, it will be expanded during glyph
position calculation
_textBB.init();
osg::Vec2 startOfLine_coords(0.0f,0.0f);
osg::Vec2 cursor(startOfLine_coords);
osg::Vec2 local(0.0f,0.0f);
unsigned int previous_charcode = 0;
unsigned int linelength = 0;
bool horizontal = _layout!=VERTICAL;
bool kerning = true;
unsigned int lineNumber = 0;
activefont-setFontResolution(_fontWidth,_fontHeight);
float hr = _characterHeight/(float)activefont-getFontHeight();
float wr = hr/_characterAspectRatio;
for(String::iterator itr=_text.begin();
itr!=_text.end();
)
{
// record the start of the current line
String::iterator startOfLine_itr = itr;
// find the end of the current line.
osg::Vec2 endOfLine_coords(cursor);
String::iterator endOfLine_itr =
computeLastCharacterOnLine(endOfLine_coords, itr,_text.end());
linelength = endOfLine_itr - startOfLine_itr;
// Set line position to correct alignment.
switch(_layout)
{
case LEFT_TO_RIGHT:
{
switch(_alignment)
{
// nothing to be done for these
//case LEFT_TOP:
//case LEFT_CENTER:
//case LEFT_BOTTOM:
//case LEFT_BASE_LINE:
//case LEFT_BOTTOM_BASE_LINE:
// break;
case CENTER_TOP:
case CENTER_CENTER:
case CENTER_BOTTOM:
case CENTER_BASE_LINE:
case CENTER_BOTTOM_BASE_LINE:
cursor.x() = (cursor.x() - endOfLine_coords.x()) *
0.5f;
break;
case RIGHT_TOP:
case RIGHT_CENTER:
case RIGHT_BOTTOM:
case RIGHT_BASE_LINE:
case RIGHT_BOTTOM_BASE_LINE:
cursor.x() = cursor.x() - endOfLine_coords.x();
break;
default:
break;
}
break;
}
case RIGHT_TO_LEFT:
{
switch(_alignment)
{
case LEFT_TOP:
case LEFT_CENTER:
case LEFT_BOTTOM:
case LEFT_BASE_LINE:
case LEFT_BOTTOM_BASE_LINE:
cursor.x() = 2*cursor.x() - endOfLine_coords.x();
break;
case CENTER_TOP:
case CENTER_CENTER:
case CENTER_BOTTOM:
case CENTER_BASE_LINE:
case CENTER_BOTTOM_BASE_LINE:
cursor.x() = cursor.x() +
[osg-users] osgWidget 0.1.6
I tagged a 0.1.6 of osgWidget: http://osgwidget.googlecode.com I really wouldn't even bother posting about it to be honest but I need a bit of help if anyone is willing to try it. :) Upon building osgWidget (you'll want to get the monospace font and the osgText.cpp patch for maximum font clarity, but they aren't necessary), run the osgwidgetinput example and press the following keys: n SPACE Where that's the actual key 'n' and the spacebar. Something really bizarre is happening on my machine and I'm beginning to think it's a driver bug... what happens though is that I get an Floating Point Exception inside of NVidia's libGL, and it seems to have something to do with the space character in some context. If you immediately insert a space character, you can then follow that with any series of key presses you like, including spaces or otherwise. Anyways, this isn't a big deal (I'm sure I'll get it figured out), but I just wanted to let folks know I'm still alive and things are chugging along slowly. :) (I've been extremely busy these last few weeks writing some system-auditing software in Python for a client, and haven't had much time for hobby code...) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget 0.1.6
I downgraded to the latest Linux NVidia legacy driver and the problem
went away.
...go figure...
Full speed ahead!
On Tue, 2008-03-11 at 13:19 -0700, Mark Sciabica wrote:
Check that new text code I posted. I initially had problems handling
the space character because it's implemented as having zero height and
width.
First make sure I sent you the right version: fHorizQuadMargin and
fVertQuadMargin initialization should be checking for vDiff nonzero
before dividing. My driver didn't like when I forgot to do that. Also,
the code assumes that the texture width/height are nonzero. If this
assumption is incorrect, the division by zero at that point might be
causing a problem.
Other than that, the only thing I can see a driver tripping up on is
creation of a zero area quad (which a space will end up being) with
different texture coordinates at each vertex. This will give an
infinite rate of change of texture coordinates across the primitive
which might be confusing the driver.
To see if this is the problem, try the following code to avoid adding
unnecessary margins to zero width glyphs.
float fHorizTCMargin = 1.0f / glyph-getTexture()-
getTextureWidth();
float fVertTCMargin = 1.0f / glyph-getTexture()-
getTextureHeight();
float fHorizQuadMargin;
if (vDiff.x() == 0.0f)
{
fHorizQuadMargin = 0;
}
else
{
fHorizQuadMargin = width * fHorizTCMargin /
vDiff.x();
mintc.x() -= fHorizTCMargin;
maxtc.x() += fHorizTCMargin;
}
if (vDiff.y() == 0.0f)
{
fVertQuadMargin = 0;
}
else
{
fVertQuadMargin = height * fVertTCMargin /
vDiff.y();
mintc.y() -= fVertTCMargin;
maxtc.y() += fVertTCMargin;
}
On Mar 11, 10:46 am, Jeremy Moles [EMAIL PROTECTED] wrote:
I tagged a 0.1.6 of osgWidget:
http://osgwidget.googlecode.com
I really wouldn't even bother posting about it to be honest but I need a
bit of help if anyone is willing to try it. :)
Upon building osgWidget (you'll want to get the monospace font and the
osgText.cpp patch for maximum font clarity, but they aren't necessary),
run the osgwidgetinput example and press the following keys:
n
SPACE
Where that's the actual key 'n' and the spacebar. Something really
bizarre is happening on my machine and I'm beginning to think it's a
driver bug... what happens though is that I get an Floating Point
Exception inside of NVidia's libGL, and it seems to have something to do
with the space character in some context. If you immediately insert a
space character, you can then follow that with any series of key presses
you like, including spaces or otherwise.
Anyways, this isn't a big deal (I'm sure I'll get it figured out), but I
just wanted to let folks know I'm still alive and things are chugging
along slowly. :)
(I've been extremely busy these last few weeks writing some
system-auditing software in Python for a client, and haven't had much
time for hobby code...)
___
osg-users mailing list
[EMAIL
PROTECTED]://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph...
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget 0.1.6 /osgText
Version 96.43.05 On Thu, 2008-03-13 at 19:21 +1300, Gert van Maren wrote: Hi Jeremy, I am getting similar crashes in osgText - nvogl.dll - division by zero. If I get rid of all spaces in my text - no crashes. I am running a GeForce 8800 GTS. 169.21 forceware drivers. Which legacy driver did you go to? Regards Gert On Thu, 13 Mar 2008 13:31:14 +1300, [EMAIL PROTECTED] wrote: I downgraded to the latest Linux NVidia legacy driver and the problem went away. ...go figure... Full speed ahead! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget 0.1.6 /osgText
On Fri, 2008-03-14 at 20:12 +1300, Gert van Maren wrote: Hi Robert, Looks like it. I have to go back to 97.XX driver to get rid of the crash but now I get other issues - BSOD occasionally. Is it osgWidget causing the BSOD, or just other things with that driver version? If I could track down a workaround for newer versions, I most certainly would--but every debugging app I've run watches the crash happen in proprietary libGL and stops there... G Hi Gert, This is almost certainly a driver bug... If getting rid of spaces fixes the problem perhaps its the spaces rendering in with coincident vertices or something, legal but triggering the bug no less. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgViewer::computeIntersections - Same Drawable Twice
While working through some strange picking problems in osgWidget (and,
by the way, SVN osgWidget is _TOTALLY_ busted, so please don't even
bother with it :)), I noticed that at some XY coordinates
osgViewer::computeIntersections is returning an Intersection object for
the same Drawable twice. I'm not quite sure what causes this, but I used
the followed code (psuedo) to verify it:
for(x = 0; x screenWidth; x++) {
for(y = 0; y screenHeight; y++) {
v.computeIntr(x, y, i, MY_MASK)
}
}
...with only a single Drawable (Widget) on the screen at the time, which
simulates a person moving their cursor over every pixel. There's no
pattern that I can see to the times this occurs, and it isn't something
I've been able to fix by changing the threading model or
enabling/disabling vsync.
I can certainly add code to guarantee that my own internal PickResults
object doesn't add the same Drawable more than once, but I wanted to
throw this question out there before going down that path. Is it
perfectly acceptable for computeIntersections to return the same
Drawable twice?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer::computeIntersections - Same Drawable Twice
I'll work up a base example and see if it occurs there or just within my
own code...
On Thu, 2008-03-20 at 14:36 +, Robert Osfield wrote:
Hi Jeremy,
This might be an osgUtil bug, we'd need to recreate it on one of the
core examples and go from there.
Robert.
On Thu, Mar 20, 2008 at 2:27 PM, Jeremy Moles [EMAIL PROTECTED] wrote:
While working through some strange picking problems in osgWidget (and,
by the way, SVN osgWidget is _TOTALLY_ busted, so please don't even
bother with it :)), I noticed that at some XY coordinates
osgViewer::computeIntersections is returning an Intersection object for
the same Drawable twice. I'm not quite sure what causes this, but I used
the followed code (psuedo) to verify it:
for(x = 0; x screenWidth; x++) {
for(y = 0; y screenHeight; y++) {
v.computeIntr(x, y, i, MY_MASK)
}
}
...with only a single Drawable (Widget) on the screen at the time, which
simulates a person moving their cursor over every pixel. There's no
pattern that I can see to the times this occurs, and it isn't something
I've been able to fix by changing the threading model or
enabling/disabling vsync.
I can certainly add code to guarantee that my own internal PickResults
object doesn't add the same Drawable more than once, but I wanted to
throw this question out there before going down that path. Is it
perfectly acceptable for computeIntersections to return the same
Drawable twice?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Mac OpenGL integration / CGLMacro.h
On Thu, 2008-03-20 at 12:32 +, Robert Osfield wrote: Hi Raphael, The changes of the OSG uses this tricked out non standard vendor lock-in mechanism are 0. I just wanted to make sure that everyone saw Robert use the phrase ticked out. That's awesome. If such an extension was available across platforms it might make some sense, but given the massive amount of changes it'd require, for a minor platform like OSX, and the likely small performance delta they might give anyway I think it would be huge waste of resources and added code complexity, associated bugs and testing. It would in the end be an utter nightmare to maintain for little gain for a small number of users. Far more interesting is items like OpenGL-ES and OpenGL 3.x, this is the future of OpenGL, not a silly little detour Apple hopes to hook you into to make you apps even more tied to a single platform. Robert. On Thu, Mar 20, 2008 at 11:22 AM, Raphael Sebbe [EMAIL PROTECTED] wrote: Hi all, On Mac OS X, there is a possibility of using a special mechanism for OpenGL calls, that is, you include CGLMacros.h in your source, and all gl*** calls take an implicit additional parameter, the context. This makes the use of a current active context unnecessary, gives better performance and it works better with threads. Developers are encouraged to use that mechanism. Some apps (thinking of Quartz Composer) strongly suggest that this is used for their plugins, drawing to the given context, and discourage changing the current OpenGL context. I guess we're not far from a suggest becoming a require in the future. The way it works is that you have to define a local variable with the name cgl_ctx, and that variable is passed as first argument to the special gl calls: CGLContextObj cgl_ctx = aContext; glBegin(GL_LINES); // which actually is like _blaBegin(cgl_ctx, GL_LINES), because of CGLMacro.h inclusion // this won't compile if cgl_ctx is not defined So my question is: what is your thought about integrating this mechanism in OSG? Thanks, Raphael ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer::computeIntersections - Same Drawable Twice
Okay, I figured this out. :) I've attached a file called osgpickbug if
you want to look at it, but this is a misnomer--it's not actually a bug.
At least, I don't think it is.
What is happening is that when the intersection occurs exactly on the
hypotenuses of the two triangles that form the quad (the Widget), both
are (naturally) being returned. I don't know if I should feel clever for
solving this or embarrassed that I even brought it up. :) At any rate,
perhaps people in the future will find this post archived if they run
into the same thing...
On Thu, 2008-03-20 at 14:36 +, Robert Osfield wrote:
Hi Jeremy,
This might be an osgUtil bug, we'd need to recreate it on one of the
core examples and go from there.
Robert.
On Thu, Mar 20, 2008 at 2:27 PM, Jeremy Moles [EMAIL PROTECTED] wrote:
While working through some strange picking problems in osgWidget (and,
by the way, SVN osgWidget is _TOTALLY_ busted, so please don't even
bother with it :)), I noticed that at some XY coordinates
osgViewer::computeIntersections is returning an Intersection object for
the same Drawable twice. I'm not quite sure what causes this, but I used
the followed code (psuedo) to verify it:
for(x = 0; x screenWidth; x++) {
for(y = 0; y screenHeight; y++) {
v.computeIntr(x, y, i, MY_MASK)
}
}
...with only a single Drawable (Widget) on the screen at the time, which
simulates a person moving their cursor over every pixel. There's no
pattern that I can see to the times this occurs, and it isn't something
I've been able to fix by changing the threading model or
enabling/disabling vsync.
I can certainly add code to guarantee that my own internal PickResults
object doesn't add the same Drawable more than once, but I wanted to
throw this question out there before going down that path. Is it
perfectly acceptable for computeIntersections to return the same
Drawable twice?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
#include iostream
#include osg/Array
#include osg/Geode
#include osg/Geometry
#include osg/MatrixTransform
#include osg/BlendFunc
#include osgGA/StateSetManipulator
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
typedef osg::Vec2Array TexCoordArray;
typedef osg::Vec3Array PointArray;
typedef osg::Vec4Array ColorArray;
typedef TexCoordArray::value_type TexCoord;
typedef PointArray::value_typePoint;
typedef ColorArray::value_typeColor;
typedef TexCoord::value_type texcoord_type;
typedef Point::value_typepoint_type;
typedef Color::value_typecolor_type;
typedef osgUtil::LineSegmentIntersector::Intersections Intersections;
const unsigned int MASK_2D = 0xF000;
const floatSCREEN_WIDTH = 1280.0f;
const floatSCREEN_HEIGHT = 1024.0f;
class OSG_EXPORT Widget: public osg::Geometry {
enum _POINT {
LL = 0,
LR = 1,
UR = 2,
UL = 3
};
static osg::ref_ptrPointArray _norms;
protected:
PointArray* _verts() {
return dynamic_castPointArray*(getVertexArray());
}
ColorArray* _cols() {
return dynamic_castColorArray*(getColorArray());
}
public:
Widget(point_type = 0.0f, point_type = 0.0f);
void setDimensions(
point_type = -1.0f,
point_type = -1.0f,
point_type = -1.0f,
point_type = -1.0f,
point_type = -1.0f
);
void setColor(color_type, color_type, color_type, color_type);
};
osg::ref_ptrPointArray Widget::_norms;
Widget::Widget(point_type w, point_type h) {
if(!_norms.valid()) {
_norms = new PointArray(1);
(*_norms)[0].set(0.0f, 0.0f, 1.0f);
(*_norms)[0].normalize();
}
TexCoordArray* texs = new TexCoordArray(4);
std::fill(texs-begin(), texs-end(), osg::Vec2(0.0f, 0.0f));
setUseDisplayList(false);
setDataVariance(osg::Object::DYNAMIC);
setVertexArray(new PointArray(4));
setColorArray(new ColorArray(4));
setNormalArray(_norms.get());
setTexCoordArray(0, texs);
setNormalBinding(osg::Geometry::BIND_OVERALL);
setColorBinding(osg::Geometry::BIND_PER_VERTEX);
addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::QUADS, 0, 4));
setDimensions(0.0f, 0.0f, w, h);
setColor(1.0f, 1.0f, 1.0f, 0.5f);
getOrCreateStateSet()-setMode(GL_BLEND, osg::StateAttribute::ON);
getOrCreateStateSet()-setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
}
void Widget::setDimensions(
point_type x,
point_type y,
point_type w,
point_type h,
point_type z
) {
PointArray* verts = _verts();
if(x == -1.0f) x = (*verts)[LL].x();
if(y == -1.0f) y = (*verts)[LL].y();
if(w == -1.0f) w = (*verts)[LR].x() - (*verts)[LL].x();
if(h == -1.0f) h = (*verts)[UL].y() - (*verts)[LL].y();
if(z == -1.0f) z = 0.0f;
(*verts)[LL].set(x, y, z);
(*verts)[LR].set(x + w, y, z);
(*verts)[UR].set(x + w, y + h, z);
(*verts)[UL].set(x, y + h
[osg-users] osgText Character/Glyph Enumeration
Is there a standard/preferred way to iterate over every character in
an osgText instance in order to query information about it's location,
etc? I'll need to be able to do this for osgWidget--in particular, to be
able to position a cursor properly within a bit of text. I have the
following code:
--
const osgText::Text::TextureGlyphQuadMap tgqm =
_text-getTextureGlyphQuadMap();
const osgText::Text::TextureGlyphQuadMap::const_iterator tgqmi =
tgqm.begin();
const osgText::Text::GlyphQuads gq = tgqmi-second;
for(unsigned int i = 0; i gq.getGlyphs().size(); i++) {
osg::Vec2 c2 = gq.getCoords()[i];
osg::Vec3 c3 = gq.getTransformedCoords(0)[i];
}
--
In the above code, should c2 and c3 be sufficient for this purpose? They
don't appear to contain the values I expect, but this is almost
certainly because I'm misusing it...
Also, this may be one of the things you'll be recoding in osgText when
the time comes, so perhaps it may be best for me to simply wait until
then before tackling this issue.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Settings for the GPU Challenged?
On Mon, 2008-03-24 at 21:23 +, Robert Osfield wrote: Hi Rick, Have a look at the osg::GraphicsContext::WindowingSystemInterface. The setScreenResolution method is what you want. Its implemented under Windows, and under Linux if you enable the support, I don't recall the details off the cuff though. Hmm, I think I actually coded this. :) But I don't remember... Oh yeah! Be sure and build with XRANDR support under Linux and it'll work. Yep. Robert. On Mon, Mar 24, 2008 at 8:35 PM, Rick Pingry [EMAIL PROTECTED] wrote: Hello all, Is there a way to set the resolution of the screen itself for gaming? Lets say you have your viewer window full screen, but the player is on a machine that does not have quite the hot graphics card, so they want to dump their resolution to keep the frame rate up. Are there any other things they can tweak in addition to this? I had already thought of providing lower level of detail models, turning off extra lights, turning off anti-aliasing, and using lower res images. Anything else I can do for my players that are GPU challenged? Thanks, -- Rick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget removeWidget not implemented
Yeah, I just haven't got around to it yet. :) I can add it later today, but I've been obsessed with getting some of the more difficult stuff done with regards to layer management and text... On Mon, 2008-03-24 at 18:21 -0400, Leontyev, Sergey wrote: Hello Jeremy, I noticed removeWidget function is not implemented yet... is there a reason it is not implemented? I looked at the code and I am not sure how to do it at all... Sergey ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget removeWidget not implemented
Yes, please do... On Tue, 2008-03-25 at 11:22 -0400, Leontyev, Sergey wrote: Sure, I can send it, I have the followings so don't be surprised Panel inherited from Canvas Button Inherited from Label ListBox inherited from Panel Should I send a zip with my project to your email? Right now background of the internal Canvas is missing Sergey -Original Message- From: Leontyev, Sergey Sent: Tuesday, March 25, 2008 10:56 AM To: 'osg-users@lists.openscenegraph.org' Subject: RE: osgWidget removeWidget not implemented On Tue, 2008-03-25 at 10:56 -0400, Leontyev, Sergey wrote: Jeremy, Thanks I have tried implementing a listbox element, it turned out to be somewhat easy, however I definitely need releaseWidget:-) Glad to hear it! :) Things will continue to get much easier as the code matures... Another question: I noticed when I have a Canvas within Canvas, the internal canvas does not have it is own background. Layering like this is the big thing I'm working on now. It doesn't work reliable 100% in any case at the moment, but it's closer every day. I tried to set different layers (low, high and etc). And when I do that widgets inside of that internal canvas disappear sometimes when the canvas when moved to certain parts of the screen, do you have any ideas of why this is happening? Are you in a position where you can you send me your code? Sergey -Original Message- From: Leontyev, Sergey Sent: Monday, March 24, 2008 6:21 PM To: osg-users at lists.openscenegraph.org Subject: osgWidget removeWidget not implemented Yeah, I just haven't got around to it yet. :) I can add it later today, but I've been obsessed with getting some of the more difficult stuff done with regards to layer management and text... On Mon, 2008-03-24 at 18:21 -0400, Leontyev, Sergey wrote: Hello Jeremy, I noticed removeWidget function is not implemented yet... is there a reason it is not implemented? I looked at the code and I am not sure how to do it at all... Sergey ___ osg-users mailing list osg-users at lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users at lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText + NVidia driver bug fix checked in
WOO-HOO! This fixes the exact bug I was seeing in osgWidget, too! Awesome... On Sat, 2008-03-29 at 09:12 +, Robert Osfield wrote: Hi All, Thanks to Sherman Wilcox the cause of the crash in osgText looks to have been tracked down to a problem with some NVidia drivers handling subloading of 0 sized data that was triggered by spaces in text. While this actually is a legal size but it causes the NVidia driver to crash no less - so very much looks to be an Nvidia driver bug hence why most users don't see it. However, it doesn't actually make much sense to call OpenGL with a 0 sized subload so we can easily work around but not calling OpenGL in this instance. I've checked in Sherman's fix, could users who've seen this problem do an svn update and let me know how you get on. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.3.7 dev release tagged.
On Tue, 2008-04-01 at 23:54 +0200, Mattias Helsing wrote: pfhiey, you almost gave me a stroke. Me too, I was actually cussing to my co-workers. :) On Tue, Apr 1, 2008 at 11:37 PM, Robert Osfield [EMAIL PROTECTED] wrote: One more thing... In the light of the recent efforts from Microsoft to support standards and for opening their source code. I've been thinking of making this one the last release before tagging in 2.4 next week or so. Then I will be starting to move OpenSceneGraph from exclusive OpenGL support to support also DirectX natively. Yes I know ... But that's not all, here is the list of features that 3.0 will bring : - fully written in C#, .NET Framework 3.5 compliant - full support of Windows Presentation Foundation (WPF) to enable seemless graphical UI experience inside your 3D applications - MSDN class documentation for all hidden features available in compressed XHTML - new osgDB plugins that will support OOXML import/export that will replace OpenSceneGraph old ascii and binary formats - native Excel support to define complex Viewer configurations - native Word support to replace osgText - support for All Microsoft optical mouse buttons This will however not be possible without full commitment of the community and funding ! Make your voices heard now if you want to join the new era in open source computer graphics software soon to be industry. 2008/4/1, Robert Osfield [EMAIL PROTECTED]: Hi All, I have now tagged the OpenSceneGraph-2.3.7 developer release, details can be found at: http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases * OpenSceneGraph-2.3.7, released on 1st April 2008. Changes include : new OpenFlight writer support and libcurl based http reader have been introduced, OpenThreads sources have now been moved directly into the OpenSceneGraph SVN removing the old use of svn:externals, and various bug and build fixes. source package : OpenSceneGraph-2.3.7.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.3.7 OpenSceneGraph That's all folks :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Robert. the other :-) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Need Build Support OSG 2.2.0\STLPort 4.5\VC 6
On Wed, 2008-04-02 at 16:28 +0200, Milan Simunek wrote: Hi, I am in a similar situation and therefore still using v1.2. I was hoping to tweak the v2.4 to compile with VC6 knowing that I have successfully compiled v1.2 and the OSG is multi-platform so there should be no a-priori reason why not. Or are they some code-structures now used in v2.x that make it plainly impossible now? I am perfectly aware of an extra time I will have to spend on this. But my experiences have taught me that the effort to learn a new IDE and mainly to overcome its drawbacks and hidden bugs is many times not worth of it (and surely not for every two-year period a new IDE is released). Of course I would prefer to know in advance if there is no chance to use v2.x in VC6 and then will probably stay in v1.2. Thanks for opinions, It's a shame when the IDE constrains your ability to use the best available version of a piece of software. :( In my opinion, it is the purpose of an IDE to make this process as easily and modular as possible, but that's just me. Hopefully someone here can help... Then again, if you consider VI an IDE, I would absolutely die without it. Luckily, Open Source to the rescue... :) Milan - Original Message - From: Paul Martz [EMAIL PROTECTED] To: 'OpenSceneGraph Users' osg-users@lists.openscenegraph.org Sent: Wednesday, April 02, 2008 12:55 AM Subject: Re: [osg-users] Need Build Support OSG 2.2.0\STLPort 4.5\VC 6 Hi Judie -- I don't think anyone is using VC6 for OSG anymore due to exactly the types of problems you've encountered. VC6's STL isn't up to par, and the various hacks to get around that (STLPort) are difficult tow work with. Robert might comment but I believe OSG v2.0 officially dropped support for VC6. -Paul _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Judie Stanley Sent: Tuesday, April 01, 2008 4:39 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Need Build Support OSG 2.2.0\STLPort 4.5\VC 6 Hi, I am new to this community. To qualify, let me say that I have downloaded all the files for building the OpenSceneGraph 2.2.0 osg core plus the applications and examples. I have configured builds for both VC 8 and VC 6. I installed SVN so I could optain the latest 3rdParty items. I have built the VC 8 configuration just fine. My problem is, our project has to be built using VC 6. So I also read and configured everything for VC 6. I built and used STLPort 4.5 but I get the following error when used with the osg build (and I googled and tried everything I could find to resolve it - rest assured my stlPort include and library paths come before the Microsoft SDK ones). When using STLPort 4.5 - I get these errors for the OpenThreads: Win32Thread.cpp C:\PROGRAM FILES\MICROSOFT SDK\INCLUDE\winbase.h(1392) : error C2733: second C linkage of overloaded function 'InterlockedIncrement' not allowed C:\PROGRAM FILES\MICROSOFT SDK\INCLUDE\winbase.h(1390) : see declaration of 'InterlockedIncrement' C:\PROGRAM FILES\MICROSOFT SDK\INCLUDE\winbase.h(1399) : error C2733: second C linkage of overloaded function 'InterlockedDecrement' not allowed C:\PROGRAM FILES\MICROSOFT SDK\INCLUDE\winbase.h(1397) : see declaration of 'InterlockedDecrement' C:\PROGRAM FILES\MICROSOFT SDK\INCLUDE\winbase.h(1407) : error C2733: second C linkage of overloaded function 'InterlockedExchange' not allowed C:\PROGRAM FILES\MICROSOFT SDK\INCLUDE\winbase.h(1404) : see declaration of 'InterlockedExchange' But we have an older version of STLPort that is used to build our project in VC6 which also has the 1.2 version of OpenSceneGraph. I was hoping to update us to the 2.2.0 version, however. So when I use this older version of STLPort (and I can't find the version number anywhere), It gets past the above error and the OpenThreads project builds just fine, but then I get the following errors: Configuration: osg - Win32 Debug Compiling... AnimationPath.cpp C:\Program Files\OpenSceneGraph\osgsrc\OpenSceneGraph\include\osg/ OperationThread(35) : error C2437: 'Referenced' : already initialized Billboard.cpp C:\Program Files\OpenSceneGraph\osgsrc\OpenSceneGraph\include\osg/ OperationThread(35) : error C2437: 'Referenced' : already initialized BufferObject.cpp C:\Program Files\OpenSceneGraph\osgsrc\OpenSceneGraph\src\osg \BufferObject.cpp(408) : error C2374: 'itr' : redefinition; multiple initialization C:\Program Files\OpenSceneGraph\osgsrc\OpenSceneGraph\src\osg \BufferObject.cpp(356) : see declaration of 'itr' C:\Program Files\OpenSceneGraph\osgsrc\OpenSceneGraph\src\osg \BufferObject.cpp(577) : error C2374: 'itr' : redefinition; multiple initialization C:\Program
Re: [osg-users] Need Build Support OSG 2.2.0\STLPort 4.5\VC 6
On Wed, 2008-04-02 at 11:23 -0400, Jean-Sébastien Guay wrote: Hi Milan, Judie, It's a shame when the IDE constrains your ability to use the best available version of a piece of software. In addition to what Paul and Jeremy said, I find it a shame for other reasons. VC6 was just a horrible compiler, with a horrible standard library implementation. Upgrading will give you much more than just being able to compile and use OSG 2.x, including using multiple cores for compilation, better optimization, better debugging, a *much* more standards-compliant STL/Standard C++ Library implementation, etc. 2 years is a long time in computing. Just look at how far OSG has come in 2 years, and try to predict where it will be 2 years from now. The J-S, there's no need to try and predict! Robert clearly indicated yesterday that will be using DirectX VERY SOON and, paramount to everything else, will finally have support for ALL OF THE OPTICAL MOUSE BUTTONS! :) more you put off following new versions of your tools, the harder the upgrade will be (but then again, it doesn't pay to be reckless with upgrades either, I'm just advocating a balanced approach). My own 0.02$. J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Device Input
On Thu, 2008-04-03 at 15:23 -0300, Renan Mendes wrote: Hi, I'm working on a project that requires the use of a new input device, called space navigator. I have the method that gets the 6 coordinates from it. I'd like to know how to get it at every frame. I thought of using a callback, but it doesn't seem right, for the object from that class is not conceptually a osg::Node. Can I include it in my viewer.run() ? It sounds like what you really want is a subclass of osgGA::GUIEventHandler that queries the device on each FRAME event. Then, you add your handler to the viewer, just like the TrackballManipulator object. I do this regularly in osgWidget. Thanks for your tip, Renan M Z Mendes ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Zero Ballistics - open beta
On Thu, 2008-04-03 at 21:14 +0200, Michael Ebner wrote: Hello OpenSceneGraph community! Sorry for spamming the list a bit, but it is not without any reason. We are using OSG in our game and it really helped us a lot in developing Zero Ballistics, therefore i really want to thank all the people who helped making OSG such a stable, mature, flexible but still fast scene graph library! So here it comes: Our team at QuantiCode is proud to announce that we have released a public beta version of our game Zero Ballistics ! The game is designed as a multiplayer online title, featuring some fast-paced tank action. There are two opposing teams battling each other with heavily armed and armored tanks. Players control their tank from the ego-perspective and fire weapons with a ballistic trajectory at their enemies, which requires a good aiming skill. Each player can equip his tank with different primary and secondary wepaons and can choose from a range of additional skills. As the game progresses, players are able to upgrade their tanks with weapon, speed and armor enhancements. Please visit our website http://www.zeroballistics.com for more information and download the client there! Hopefully you will enjoy playing our game and you are welcome to post any feedback to our forum at http://forum.zeroballistics.com Any ETA on the Linux client? :) kind regards, Michael ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ANN: osgWidget 0.1.7
Hey folks... It's been a month almost since the last testing release of osgWidget, but there have been lots of changes since then and I wanted to make sure people know I'm still alive and working hard. As usual, the CHANGELOG tells the story much better than I can: http://code.google.com/p/osgwidget/source/browse/tags/0.1.7/CHANGELOG I forgot to mention in the CHANGELOG, however, that an example is included now showing how easy it is to attach a GLSL shader to a Window (or just a Widget); not that anyone would expect that to be hard with OSG in the first place. Still lots of work to do (font clarity issues keep kicking my butt, but hopefully Robert will have time soon to poke at osgText's implementation in the next few months), but getting closer all the time... As usual, keep the e-mails coming! They are what motivate me to write code in my free time instead of wasting it away on video games. :) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] use of ref_ptr
Another thing I believe is often overlooked is using ref_ptr's with
objects who attempt to properly support copy construction. It's such a
hard thing to get right that I plan eventually adding a chapter about it
in the osgWidget docs, when the time comes.
It's not uncommon to want to keep ref_ptr's around to objects you add to
a scene in your own classes (OSG-derived or otherwise), but properly
setting that ref_ptr again in the new object after a call to clone() can
be tricky depending on what type of osg::CopyOp you use. Maybe a chapter
on this could one day go into the QSG, though it's more of a hybrid
topic between C++ and OSG itself.
On Wed, 2008-04-09 at 18:05 +0200, [EMAIL PROTECTED] wrote:
I just started using OSG and have never used ref_ptr's before, though I've
read the A Short Introduction to the Basic Principles of the Open Scene
Graph and belive I understand the concept. But I wonder if you have any
advice on the use of ref_ptr's on OSG objects, and If you use them in some
standard way.
I recon all the objects that inherits from Referenced should use ref_ptr
for safer memory alloction/deleting, but I guess it's just a subjective
choice.
The tutorials though use dumb pointers as in the Basic Geometry example:
...
int main()
{
...
osg::Group* root = new osg::Group();
osg::Geode* pyramidGeode = new osg::Geode();
osg::Geometry* pyramidGeometry = new osg::Geometry();
but i guess it's just for simplicity.
In the guide A Short Introduction to the Basic Principles of the Open Scene
Graph on the use of ref_ptr, they first create a node using ref pointer,
then they add a node using new, and say:
Line 25 does more or less the same thing as the previous case. The
difference is that the geode is allocated with new and added as group's
child in a single line of code. This is quite safe, too, because there are
not many bad things that can happen in between (after all, there is no
in between.)
that may be a little missleading since it's not a smart pointer, and needs to
be deleted explicitly.
Erlend
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Installing OSG in Ubuntu
Also: # apt-get install apt-file # apt-file update ...and when something says you're missing Foobar.h... # apt-file search Foobar.h ...and install. Never goes wrong. :) On Mon, 2008-04-14 at 12:12 +0200, Alberto Luaces wrote: A starting point to get OSG and the most of its plugins would be: apt-get install g++ cmake mesa-common-dev libungif4-dev libfreetype6-dev libjasper-dev libtiff4-dev libxine-dev ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using Custom Mouse Cursor
On Tue, 2008-04-15 at 18:04 +0200, Guy wrote: Hello, I have no suggestion to solve the problem, but if the functionality to set the default cursor will be added, it should support a 3D cursor too. That means, hiding the operating system cursor and moving 3D object on the screen space according to the mouse movements. By the way, isn't there some sort of that implementation in osgWidget? Well, I can't really comment on the 3D cursor, but I will certainly be adding normal cursor changing support to osgWidget. I haven't begun to investigate this yet, but I commonly refer to SDL on issues such as these, so I'm sure they have a lot of good example code on how such a thing can be accomplished--and thus, integrated into OSG, if it isn't already. Thanks, Guy. __ From:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Beverage Sent: Monday, April 14, 2008 11:18 PM To: osg users Subject: [osg-users] Using Custom Mouse Cursor Hi all, I'm attempting to use OSG embedded in a C# window like hesicong and Glenn Waldron have recently discussed on the osg-users mailing list. One issue that I'm running into is changing the Cursor property on my mouse form. a custom mouse cursor in my form. GraphicsWindowWin32 manages the current cursor as one of the ones defined in the GraphicsWindow::MouseCursor enumeration so I can't use a custom cursor (as far as I can tell). If I set the cursor manually using ::SetCursor, it gets override by GraphicsWindowWin32 because it calls ::SetCursor in response to every WM_SETCURSOR call and passes in _currentCursor. I've tried setting useCursor to false in the traits of the graphics context and calling ::SetCursor on my own, but this causes the cursor to flicker very badly because GraphicsWindowWin32 calls ::SetCursor(NULL) if use cursor is set to false. It seems like there needs to be an option to set a custom cursor by passing in an HCURSOR or a way to say don't manage the mouse cursor in the Traits class. Any suggestions? Jason ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Providing A Lock Method in osgWidget
Hello all!
In it's current form, osgWidget creates each Widget (an osg::Geometry
subclass) using the following method calls:
setUseDisplayList(false);
setDataVariance(osg::Object::DYNAMIC);
(I do not, however, modify anything with regards to
setUseVertexBufferObjects, so it remains whatever the Drawable/Geometry
default is).
My question, then, is twofold:
1. Given the above (and the fact that I am able to modify the
osg::Array objects within the Widget directly and see immediate
results), is it safe to say I am forcing the drawing implementation to
use the slowest, immediate mode for rendering? I've always assumed
this, and have been comfortable with that during development.
2. If the above is true, consider the following situation: a user
creates his interface element, positions, resizes, colors it, etc. When
he's done with this he knows that, for the most part, this particular
element will remain static and require no further updates. Thus, there
could be some benefit then in asking this object to reconfigure itself
to use display lists or VBOs. Is this possible? I'd call this method
locking or similar, seeing as conceptually it would prevent you from
making any direction geometry modifications as long as the object was
static. However, I'm not entirely sure I have a full understanding of
the process. Is it as easy as calling:
setDataVariance()
set{UseVertextBufferObjects/UseDisplayList}()
...or is there something more complicated required?
P. S. Is it lunch time yet? :)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Providing A Lock Method in osgWidget
On Wed, 2008-04-16 at 15:43 +0100, Robert Osfield wrote:
On Wed, Apr 16, 2008 at 3:30 PM, Jeremy Moles [EMAIL PROTECTED] wrote:
My question, then, is twofold:
1. Given the above (and the fact that I am able to modify the
osg::Array objects within the Widget directly and see immediate
results), is it safe to say I am forcing the drawing implementation to
use the slowest, immediate mode for rendering? I've always assumed
this, and have been comfortable with that during development.
Immediate mode can still use vertex arrays, this will typically be
slower than using display lists. As long as you don't use per
primitive normals/colours and vertex indices you'll still be using
OpenGL fast paths (vertex arrays) rather than slow paths
(glBegin/glVertex/glEnd) so it needn't be a major issue.
Also one needs a bit of perspective, you are unlikely to have
thousands of GUI elements all on screen at one time - so cull and draw
dispatch are very unlikely to be bottlenecks - fill rate is much more
likely a limit with GUI's with the overdraw associated with building
up layers, even then its still not likely to impact performance too
much on modern machines.
You're right about this, of course. Thanks. :)
2. If the above is true, consider the following situation: a user
creates his interface element, positions, resizes, colors it, etc. When
he's done with this he knows that, for the most part, this particular
element will remain static and require no further updates. Thus, there
could be some benefit then in asking this object to reconfigure itself
to use display lists or VBOs. Is this possible? I'd call this method
locking or similar, seeing as conceptually it would prevent you from
making any direction geometry modifications as long as the object was
static. However, I'm not entirely sure I have a full understanding of
the process. Is it as easy as calling:
setDataVariance()
set{UseVertextBufferObjects/UseDisplayList}()
...or is there something more complicated required?
Are you not overcomplicating things. If people use the code correctly
it'll work correctly, if they abuse it then the results are undefined.
Trying to add extra complexities to try and avoid all eventualities
can lead to far more problems than it solves.
P. S. Is it lunch time yet? :)
That's a third question. And yes, it's almost always lunch time
somewhere in the world ;-)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Create underwater effects
On Thu, 2008-04-17 at 10:11 +0100, Kim C Bale wrote: There isn't really anything specific to OSG that can help you with this. I am working on underwater effects at the moment and most of my work has been with shaders. Tessendorf offers a fairly comprehensive guide to ocean rendering both above and below water here: http://graphics.ucsd.edu/courses/rendering/2005/jdewall/tessendorf.pdf the papers he references in that cover most techniques. The book, Shader X5 has a good section on creating god-rays using a multi-pass technique. Aside from that osgParticle gives you the framework to create a range of particle effects such as plankton, silt on the seabed and bubbles. Osg::Fog is also useful as a quick and easy underwater cue. I also played around with multi-pass rendering and refraction shaders, refracting images above water through the ocean surface and warping the screen in general creating a kind of wobbly underwater feel. I'm afraid I can't share any code, but if you're looking for inspiration, take a look at the games BioShock or the underwater Not trying to take this thread off topic, but taking a look at BioShock should be done by everyone, not just because they have best water effects in any game to date. :) BioShock is probably the best game I've played in 5 years... the ambiance and settings and story and everything are simply without peer... sequences in Splinter Cell Double Agent, as it's where I gathered most of my ideas from. Hope that is of some help. Kim. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Loong Hin Sent: 17 April 2008 01:38 To: osg-users@lists.openscenegraph.org Subject: [osg-users] Create underwater effects Hi, Anyone has any ideas or sample codes in creating underwater effects using OSG? Thanks a lot. regards ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html * ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple cameras
On Mon, 2008-04-21 at 20:17 +0100, Robert Osfield wrote: Hi Robert, Nicolas nicely sumerised what I normally write in a couple of hundred lines, in your case you certainly have multiple independent views - the main view and the HUD view are conceptually different, so naturally these would lead to your suggestion 3 - i.e. using CompositeViewer. In the case of HUD's you can just be a bit more lazy and treat the HUD as just an overlay and not really a full view in its own right - so conceptually you'd tell yourself you have one main view and just a bit of decoration on top, in which case you make an excuse for using a slave camera and use a standard Viewer. Viewer is only slightly more straight forward to work with than CompositeViewer so that there isn't really much to gain from this. Personally I would not recommend stick a HUD into a scene graph any more, as conceptually it's harder to claim that a HUD is part of the scene, however, there are some cases where you might actually want a This raises an interesting question, Robert. osgWidget can easily use Viewer or CompositeViewer (it really just needs an osgViewer::View* for computeIntersections()), but throughout the examples and whatnot I normally just use a standard Viewer. Should I begin encouraging use of CompositeViewer instead, just as a kind of good development practice thing? HUD saved and loaded along with the rest of the scene graph, so again here you might want to bend the rules a little ;-) I'm currently implementing DotOsgWrapper proxy objects for all of osgWidget. I'm not pretending this will act as a fully-serialized state dump of an interface at any given time, but it will at least allow you to dump some semblance of your UI and view it in text form--or even load it in a perspective view to see how Windows and whatnot are layered... Since there is the same Camera setup required for almost all of these configurations it's actually not too hard to jump from one set up to the next so if you do go down one route then decide against it it shouldn't be too hard to refactor. Robert. On Mon, Apr 21, 2008 at 5:35 PM, Robert Balfour [EMAIL PROTECTED] wrote: My present osg app configuration is a single view on a single window/screen, with a hud camera overlay, which I simply added to the scenegraph with a high renderbin#. Looking at osgHud example, it seems that this can also be configured by adding the hud camera as a slave cam to the view. Or using Composite viewer, adding the hud cam as a second view. Now if I go to reconfigure my app to work over two or more windows/screens, which approach would be better: (1)multiple cameras in the scenegraph, (2)slave cameras on a single view, or (3)multiple views (using composite viewer)? I'm leaning towards (3). Thanks. Bob. -- Robert E. Balfour, Ph.D. Exec. V.P. CTO, BALFOUR Technologies LLC 960 South Broadway, Suite 108, Hicksville NY 11801 Phone: (516)513-0030 Fax: (516)513-0027 email: [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Working with text
On Tue, 2008-04-22 at 20:35 -0400, Lucas Goss wrote: I must be blind, but I can't figure out what is wrong with this small text example (attached). I wanted to load 3 fonts side by side to compare them, but the viewer only shows that last font that was loaded. I compared the code to the osgtext.cpp example and even stripped it down to just font loading and it worked fine, but it looks almost exactly like mine (which doesn't work, only shows one font). The text example that is attached loads 3 different fonts, but it doesn't matter which font you use (you can use three of the same or even the null font it still only shows one line of text instead of 3). I just want to know, why does only one show up? You're only calling -setText on text, not on textSe and textMono. On a related note: why not just use osgWidget and not worry about all this placement stuff? :) Thanks, Lucas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Working with text
On Wed, 2008-04-23 at 10:54 -0400, Lucas Goss wrote: You're only calling -setText on text, not on textSe and textMono. Whew, thanks, I was losing my mind. On a related note: why not just use osgWidget and not worry about all this placement stuff? :) I'm trying to get osgWidget working, but took a break to play around with some other stuff... Most of my development is on a Mac so I use the library frameworks, which none exists for osgWidget at the moment. So I attempted to build one but I always ran into some problem with linking or finding include files. I tried going the cmake way, but couldn't get OSG built as I ran into some errors there. So I took a break and played with osgText... I love programming... I hate working with make and friends. Now I'm on Ubuntu... built osg with cmake, but osgWidget errors when it starts to build the examples (both repositories from svn head): ... Linking CXX shared library libosgWidget.so [ 40%] Built target osgWidget Scanning dependencies of target osgwidgetaddremove [ 42%] Building CXX object examples/osgwidgetaddremove/CMakeFiles/osgwidgetaddremove.dir/osgwidgetaddremove.o Linking CXX executable osgwidgetaddremove /home/lgoss/Development/Lab/osgWidget/osgwidget/build/libosgWidget.so: undefined reference to `osgText::Text::setAxisAlignment(osgText::Text::AxisAlignment)' /home/lgoss/Development/Lab/osgWidget/osgwidget/build/libosgWidget.so: undefined reference to `osgText::Text::setAlignment(osgText::Text::AlignmentType)' /home/lgoss/Development/Lab/osgWidget/osgwidget/build/libosgWidget.so: undefined reference to `osgText::Text::setFontResolution(unsigned int, unsigned int)' /home/lgoss/Development/Lab/osgWidget/osgwidget/build/libosgWidget.so: undefined reference to `osgText::Text::setRotation(osg::Quat const)' /home/lgoss/Development/Lab/osgWidget/osgwidget/build/libosgWidget.so: undefined reference to `osgText::Text::setPosition(osg::Vec3f const)' /home/lgoss/Development/Lab/osgWidget/osgwidget/build/libosgWidget.so: undefined reference to `osgText::Text::setCharacterSize(float, float)' /home/lgoss/Development/Lab/osgWidget/osgwidget/build/libosgWidget.so: undefined reference to `osgText::Text::setText(std::basic_stringchar, std::char_traitschar, std::allocatorchar const)' collect2: ld returned 1 exit status It's not picking up -losgText for some reason, but I can't be sure. I'd be really certainly everything else built properly, since I've never seen this and no one else has reported it. Try editing examples/$EXAMPLE/CMakeLists.txt and changing: LINK_LIBRARIES(debug osgWidgetd optimized osgWidget) To: LINK_LIBRARIES( debug osgWidgetd optimized osgWidget debug osgTextoptimized osgText ) If this fixes it, I may have introduced a bug or something recently I'm not aware of in my CMake configs. Thanks, Lucas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Working with text
On Wed, 2008-04-23 at 12:31 -0400, Lucas Goss wrote: Yeah it all built properly... but that gave me a clue. So I ran: cmake .. -DCMAKE_BUILD_TYPE=Release And got past that part, but got this error (I couldn't find the io_utils file): Alas, the dangers of svn head. :) This is fixed in my local repo (uncommitted), so an SVN update in about 2 mins should do the trick... More eyes--is more testing--is more good! Scanning dependencies of target osgwidgetmenu [ 60%] Building CXX object examples/osgwidgetmenu/CMakeFiles/osgwidgetmenu.dir/osgwidgetmenu.o /home/lgoss/Development/Lab/osgWidget/osgwidget/examples/osgwidgetmenu/osgwidgetmenu.cpp:6:30: error: osgWidget/io_utils: No such file or directory /home/lgoss/Development/Lab/osgWidget/osgwidget/examples/osgwidgetmenu/osgwidgetmenu.cpp: In member function 'virtual bool ColorLabel::mousePush(double, double, const osgWidget::WindowManager*)': /home/lgoss/Development/Lab/osgWidget/osgwidget/examples/osgwidgetmenu/osgwidgetmenu.cpp:32: error: no match for 'operator' in 'std::cout *(ColorLabel*)this' ... Thanks, Lucas On Wed, Apr 23, 2008 at 10:59 AM, Jeremy Moles [EMAIL PROTECTED] wrote: On Wed, 2008-04-23 at 10:54 -0400, Lucas Goss wrote: You're only calling -setText on text, not on textSe and textMono. Whew, thanks, I was losing my mind. On a related note: why not just use osgWidget and not worry about all this placement stuff? :) I'm trying to get osgWidget working, but took a break to play around with some other stuff... Most of my development is on a Mac so I use the library frameworks, which none exists for osgWidget at the moment. So I attempted to build one but I always ran into some problem with linking or finding include files. I tried going the cmake way, but couldn't get OSG built as I ran into some errors there. So I took a break and played with osgText... I love programming... I hate working with make and friends. Now I'm on Ubuntu... built osg with cmake, but osgWidget errors when it starts to build the examples (both repositories from svn head): ... Linking CXX shared library libosgWidget.so [ 40%] Built target osgWidget Scanning dependencies of target osgwidgetaddremove [ 42%] Building CXX object examples/osgwidgetaddremove/CMakeFiles/osgwidgetaddremove.dir/osgwidgetaddremove.o Linking CXX executable osgwidgetaddremove /home/lgoss/Development/Lab/osgWidget/osgwidget/build/libosgWidget.so: undefined reference to `osgText::Text::setAxisAlignment(osgText::Text::AxisAlignment)' /home/lgoss/Development/Lab/osgWidget/osgwidget/build/libosgWidget.so: undefined reference to `osgText::Text::setAlignment(osgText::Text::AlignmentType)' /home/lgoss/Development/Lab/osgWidget/osgwidget/build/libosgWidget.so: undefined reference to `osgText::Text::setFontResolution(unsigned int, unsigned int)' /home/lgoss/Development/Lab/osgWidget/osgwidget/build/libosgWidget.so: undefined reference to `osgText::Text::setRotation(osg::Quat const)' /home/lgoss/Development/Lab/osgWidget/osgwidget/build/libosgWidget.so: undefined reference to `osgText::Text::setPosition(osg::Vec3f const)' /home/lgoss/Development/Lab/osgWidget/osgwidget/build/libosgWidget.so: undefined reference to `osgText::Text::setCharacterSize(float, float)' /home/lgoss/Development/Lab/osgWidget/osgwidget/build/libosgWidget.so: undefined reference to `osgText::Text::setText(std::basic_stringchar, std::char_traitschar, std::allocatorchar const)' collect2: ld returned 1 exit status It's not picking up -losgText for some reason, but I can't be sure. I'd be really certainly everything else built properly, since I've never seen this and no one else has reported it. Try editing examples/$EXAMPLE/CMakeLists.txt and changing: LINK_LIBRARIES(debug osgWidgetd optimized osgWidget) To: LINK_LIBRARIES( debug osgWidgetd optimized osgWidget debug osgTextoptimized osgText ) If this fixes it, I may have introduced a bug or something recently I'm not aware of in my CMake configs. Thanks, Lucas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Working with text (osgWidget)
These errors are all the result of using SVN, some of which I have an answer in the works for and some of which I do not. Also, most of your errors are caused by not having the font I use installed, which you can remedy by changing the examples to use your font of choice. :) Widgets and Windows use the size of their labels to resize themselves, so not being able to render fonts will give you lots of 0, 0 sized objects. On Wed, 2008-04-23 at 15:44 -0400, Lucas Goss wrote: More eyes--is more testing--is more good! OK, well here's some testing notes on osgWidget head: * osgwidgetaddremove -I get: Warning: font file fonts/Calibri1.ttf not found -I get a blank screen.. looked at the code and seems to go with mouse push/release * osgwidgetbox -I get a blank screen for this one too * osgwidgetinput -Clicking the button gives an error: osgWidget: Window [frame] couldn't find the Widget [Widget_2] in it's object list. -Input doesn't work with the numpad, feature request :) -Tabbing to next control works, but it doesn't go to button. Some way it would be nice to hit button with keyboard (whether enter on any control or tab to enter and select... (some kind of default accept button and default cancel button for a container control/window would be nice) * osgwidgetlabel -I get: Warning: font file fonts/Calibri1.ttf not found. -I only see a small green box at the top of the screen * osgwidgetmenu -Warning: font file fonts/Calibri1.ttf not found. osgWidget: Window [Menu_andy_mckee] can't call resizeAdd() with the values -56 and 0 ... osgWidget: Window [Menu_common] can't call resizeAdd() with the values -88 and 0 ... osgWidget: Window [Menu_lol] can't call resizeAdd() with the values -112 and 0 -No menu shows up? * osgwidgetnotebook (seems to work alright, but..) -osgWidget: Window [notebook] couldn't find the Widget [Tab_2] in it's object list. osgWidget: Window [notebook] couldn't find the Widget [Tab_1] in it's object list. osgWidget: Window [notebook] couldn't find the Widget [Tab_0] in it's object list. osgWidget: Window [notebook] couldn't find the Widget [Tab_3] in it's object list ... * osgwidgetscrolled -Looks nice, but part of the scroll window is off screen (top chopped off) Can you send me an e-mail off the lists of this? :) Thanks, Lucas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] mouse location (x,y) in pixel units
osgWidget does this, and converts the origin to the upper-left instead of lower-left in the WindowManager object just using getX/getY. They have never returned normalized coordinates in my usage... but perhaps I've been benefiting from a bug all along...? On Thu, 2008-04-24 at 13:56 +, Andrew Lett wrote: In OSG2.2 I'd like to find the 'real' x,y location of the mouse cursor. If my window is 640x480, then the value for x should be between 0 and 639, while y should be from 0 to 479. I need the x,y values in this form so that it can be injected into CEGUI correctly. The GUIEventAdapter has protected members _mx and _my, along with the access methods getX() and getY(). However, these methods both yield values between -1 and 1. While stepping through the code, the _mx and _my actually correctly hold the pixel based values I need until encountering the following section in Viewer.cpp: osg::Vec3d new_coord = osg::Vec3d(x,y,0.0) * matrix; x = new_coord.x(); y = new_coord.y(); ... event-setX(x); event-setY(y); Aside from making private changes on GUIEventAdapter, is there any other way to read the mouse x,y location in the format I need? All suggestions are very much appreciated. Sincerely, - Andrew ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Off-screen rendering
On Thu, 2008-04-24 at 15:48 -0500, Tessier, Philip wrote: All, I was able to use the osgprerender example to obtain most of what I need - the rendering of a scene into an osg::Image. As that's ALL I want, I need help with a tweak to it. It uses a viewer.run() to do the work. I've replaced this with a viewer.frame(). This produces a flicker on the screen as the viewer realizes the frame. As I'm interested in an off-screen grab, this is annoying. I'm reasonably sure that I don't want a viewer at all, but I don't know what to simplify it to. This is a copy/paste of a response Robert gave to a question like this a few months ago... -- Where supported one can use a pbuffer on Win32, X11 and Carbon implementations in osgViewer. Just create the Traits with the pbuffer option set to true, then create your GraphicsContext as per the osgcamera or osgwindows examples. -- I had recommended looking at how SDL hides the Window, but this is almost certainly a better solution. :) If you want to get real crazy you could do something like: # OSG_WINDOW=0 0 1 1 ./myApp ...but that's an abysmal hack, and still ends up showing a little tiny block you can't do anything about. :) Thanks, in advance, Phil Philip A. Tessier Northrop Grumman IT [EMAIL PROTECTED] 210-867-6775 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking as the QuickGuide example only using Viewer as embedded window, does only catch FRAME type, no mouse events!
On Mon, 2008-04-28 at 16:07 +0200, [EMAIL PROTECTED] wrote: I've created the PickHandler as in the QuickGuide book and added to my Viewer ( as embedded! ), but I cant catch mouse events, only FRAME type. Do you know what I'm doing wrong? You won't be able to use standard OSG events unless OSG created and managed the entire window. You'll have to hook into whatever API you used to create the Window (Qt, GTK, SDL, etc.) and convert the events there. The osgviewerSDL demonstrates this pretty well, and I've written an osgviewerGTK I plan on submitting once Robert gets back which converts GTK events into OSG events. Erlend ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Collada Animation
On Thu, 2008-05-01 at 16:20 +0100, Kim C Bale wrote: I’ve been using the Feeling Software ColladaMax exporter for 3DSMax to export models so that I may use them in OSG. Now plain models work a treat. However, I have been given a file that contains an animation, and the animations don’t appear to show when I load them into osgViewer. I had a feeling that they wouldn’t, but is there something that I can do to enable them? Does anybody have any experience getting Collada model animations into osg? Is it supported at all? A standard system for skeletal animation is something OSG currently lacks. There was some discussion some months back about settling on one, but that's unlikely to happen anytime soon. For now, your main option is Cal3D. However, when I'm done with osgWidget I'll probably devote that new time to helping Cedric Pinson more with AnimTK, which I really believe to be a great toolkit (though we'll have to eventually address it's usage of the GPL). I've already contributed a bit to it and can speak for it's soundness, and both myself and Cedric use Blender a great deal--so it's exporter there will be rock solid. :) I've made some videos of AnimTK mixing some simple animations from a model made in Blender, they're on the osgWidget website (because it also uses a simple osgWidget::Frame window :)) http://osgwidget.googlecode.com I can tell you this though: AnimTK is divorced from any kind of mesh format, so it wouldn't be impossible for the Collada plugin to use it to facilitate it's animation in OSG one day... Regards, Kim. * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html * ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget-0.2.0 Link Error in VC8
On Mon, 2008-05-05 at 15:12 +0800, Green wrote: There are two link errors: The first: 1osgwidgetscrolled.obj : error LNK2019: unresolved external symbol public: bool __thiscall osgWidget::Window::EmbeddedWindow::setWindow(class osgWidget::Window *) ([EMAIL PROTECTED]@[EMAIL PROTECTED]@@QAE_NPAV23@@Z) referenced in function _main I'm not sure why you'd get this error; the function absolutely exists on line 102 of Window.cpp; it's gotta' be some weird Windows thing, as I do all my development on Linux. I can try building on Windows tonight after work. Same for the error below... 1Debug\osgwidgetscrolledd.exe : fatal error LNK1120: 1 unresolved externals The second: 2EmbeddedWindow.obj : error LNK2019: unresolved external symbol public: __thiscall osgWidget::Window::EmbeddedWindow::EmbeddedWindow(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,float,float) ([EMAIL PROTECTED]@osgWidget@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@std@@[EMAIL PROTECTED]@2@@std@@[EMAIL PROTECTED]) referenced in function void __cdecl `dynamic initializer for 'g_osgWidget_EmbeddedWindowProxy''(void) (??__Eg_osgWidget_EmbeddedWindowProxy@@YAXXZ) 2Debug\osgdb_osgwidgetd.dll : fatal error LNK1120: 1 unresolved externals Could anyone tell me what’s wrong? I have checked my lib, and they are all set correctly. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget-0.2.0 Link Error in VC8
On Tue, 2008-05-06 at 00:15 +0200, Mattias Helsing wrote: Hi Green, Try putting a OSG_EXPORT between class and EmbeddedWindow in Window.h. The same goes for some other classes (CORNER and BORDER in Frame - only needed if you subclass Frame) . osgWidget isn't in a well-tested state yet and Jeremy is working hard to work up some muscles in osgWidget. Bah! You're right. I had this changed in my local repo, but it was uncomitted... hope this helps Mattias On 5/5/08, Green [EMAIL PROTECTED] wrote: There are two link errors: The first: 1osgwidgetscrolled.obj : error LNK2019: unresolved external symbol public: bool __thiscall osgWidget::Window::EmbeddedWindow::setWindow(class osgWidget::Window *) ([EMAIL PROTECTED]@[EMAIL PROTECTED]@@QAE_NPAV23@@Z) referenced in function _main 1Debug\osgwidgetscrolledd.exe : fatal error LNK1120: 1 unresolved externals The second: 2EmbeddedWindow.obj : error LNK2019: unresolved external symbol public: __thiscall osgWidget::Window::EmbeddedWindow::EmbeddedWindow(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,float,float) ([EMAIL PROTECTED]@osgWidget@@[EMAIL PROTECTED]@[EMAIL PROTECTED] @std@@[EMAIL PROTECTED]@2@@std@@[EMAIL PROTECTED]) referenced in function void __cdecl `dynamic initializer for 'g_osgWidget_EmbeddedWindowProxy''(void) (??__Eg_osgWidget_EmbeddedWindowProxy@@YAXXZ) 2Debug\osgdb_osgwidgetd.dll : fatal error LNK1120: 1 unresolved externals Could anyone tell me what's wrong? I have checked my lib, and they are all set correctly. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how a hud-camera respond to the resize event;
osgWidget handles this by using a custom EventHandler:
http://code.google.com/p/osgwidget/source/browse/trunk/src/ViewerEventHandlers.cpp#165
...the idea being that it's generally the case you want to adjust your
orthographic display by responding to the RESIZE event, and that you'll
almost never get the results you want otherwise (at least in my
experience :)).
On Tue, 2008-05-06 at 09:26 +0800, Wu Xiaodong wrote:
All. I try to render a hud-text;
I created a hud text in a geode and added it to a
slave-camera. It's good. but when i resize the view and set a new
position to the text bases on the new window rect. The text's position
seems based on the old window rect when when the slave-camera is
created.
when created, window rect is (0,0, 100,100) and the text
position is : 50,50, it's good;
when resize the window to rect (0,0,200,200) and i try to set
the text position (100,100); I hope the text should be in the center
of window, but it's out of the window range and I can see it in the
view.
how can I fix my problem?
Thanks.
xiaodong
the codes is following.
if( _hudCamera.valid() ) _hudCamera.release();
_hudCamera = new osg::Camera;
_hudCamera-setReferenceFrame(osg::Transform::ABSOLUTE_RF);
osg::ref_ptrosg::Camera camera = this-getCamera();
//update the main camera;
osg::ref_ptrosg::GraphicsContext::Traits traits;
if( camera.valid() )
{
osg::ref_ptrosg::GraphicsContext context =
camera-getGraphicsContext();
if( context.valid() )
{
traits =
const_castosg::GraphicsContext::Traits*( context-getTraits() );
if( traits.valid() )
{
_hudCamera-setGraphicsContext( context.get() );
_hudCamera-setViewport(0,0,traits-width,
traits-height );
}
}
}
if( traits.valid() ) {
_hudCamera-setProjectionMatrixAsOrtho2D(0,traits-width,0,traits-height);
_hudCamera-setViewMatrix(osg::Matrix::identity());
_hudCamera-setRenderOrder(osg::Camera::POST_RENDER);
_hudCamera-setClearMask(GL_DEPTH_BUFFER_BIT);
std::string timesFont(fonts/times.ttf);
turn lighting off for the text and disable depth test to
ensure its always ontop.
osg::Vec3 position( 10.0f,traits-height/2.0,0.0f);
osg::Geode* geode = new osg::Geode();
osg::StateSet* stateset = geode-getOrCreateStateSet();
stateset-setMode(GL_LIGHTING,osg::StateAttribute::OFF);
stateset-setMode(GL_DEPTH_TEST,osg::StateAttribute::OFF);
//--
stateset-setRenderBinDetails(11, RenderBin);
_hudCamera-addChild( geode );
osgText::Text* text = new osgText::Text;
geode-addDrawable( text );
text-setFont(timesFont);
std::stringstream ss;
sswidth:traits-widthHeight:traits-heightstd::endl;
std::string str;
ssstr;
std::wstring wstr(str.begin(), str.end());
text-setText( wstr.data() );
text-setPosition(position);
}
//
--
Xiaodong Wu
吴晓东
'Xiao' means the time and the view when the sun rises and 'dong'
means the east in Chinese
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] .ive plugin: incorrect ReadResult?
Broken up into lists of 10: 3dc 3ds ac bmp bsp cfg curl dae dds dw dxf freetype gdal geo gif glsl hdr Inventor ive jp2 jpeg logo lwo lws md2 net normals obj ogr OpenFlight osg osga osgFX osgParticle osgShadow osgSim osgTerrain osgText osgtgz osgViewer pfb pic png pnm quicktime rgb rot scale shp stl tga tgz tiff trans txf txp vrml x xine zip Also, you don't HAVE to return a ReadResult::ReadStatus enum directly; it can also be a string (I submitted a patch for this a long time ago) giving some useful error message; in this case, the status is set to ERROR_IN_READING_FILE. I'll certainly volunteer to take 10 of these, though it'll be a day or two before I can finish. :) On Tue, 2008-05-06 at 14:45 +0100, Robert Osfield wrote: Hi Bob and Paul, Bob's doc explanation for the different ReadReasult is appropriate. I must admit not have done a project wide review of the return results, the number of plugins that are available is one hindrance to this so community support would be useful. Perhaps half a dozen volunteers could take a 10 each and we'll complete in no time at all. Thoughts? Robert. On Tue, Apr 29, 2008 at 6:48 PM, Bob Kuehne [EMAIL PROTECTED] wrote: hi robert, osg community, to amplify on what paul said: * we do a lab in our course in which we explore what plugins are capable of reading/writing. * but! our results always show that plugins support an inconsistent mix of return values, sometimes returning ERROR_IN_READING_FILE when they really mean that they don't handle files of that extension, sometimes returning FILE_NOT_HANDLED when there's an error in reading the file data. * as part of our course in paris this week, we've then wondered aloud if there's an official osg policy for these return values, and if robert had an original design idea behind each return value. our impression is that these mean, as follows: FILE_NOT_HANDLED, //! file is not appropriate for this file reader, due to some incompatibility, but *not* a read error FILE_NOT_FOUND, //! file could not be found or could not be read FILE_LOADED, //! file successfully found, loaded, and converted into osg FILE_LOADED_FROM_CACHE, //! file found in cache and returned ERROR_IN_READING_FILE //! file found, loaded, but an error was encountered during processing if this interpretation of the errors are correct, i'd like to add doxygen documentation to that effect, and the above comments can be in-line replaced in the code to do so. and i've sent a fixed osgDB/ReadResult to osg-submissions for this purpose. the second thing i'd like to do, though i don't have the time, is to clean up the loaders so that the above return scheme is used consistently. the big problem with the current loaders is that there seems to not be a lot of consistency in error reporting among all loaders. thoughts? bob On Apr 29, 2008, at 12:11 PM, Paul Martz wrote: Hi Robert -- If the .ive file can't read a node file for any reason, it returns FILE_NOT_HANDLED. This is correct if the file type isn't .ive, but if it _is_ a .ive file and it is simply corrupt or something else went wrong (permissions, whatever), the plugin should return ERROR_IN_READING_FILE, shouldn't it? Many plugins appear to use return values inconsistently, so this might be a widespread issue. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgForge: what's the status?
On Wed, 2008-05-07 at 10:07 -0400, Jean-Sébastien Guay wrote: Hello Robert et al, First of all, an announcement: I have finished my Masters. My thesis was accepted unanimously and apart from some small corrections, the comments were good. I'm happy! :-) Congratulations! I was thinking of publishing my Masters project under the OSGPL. It's an interesting program (at least I think so) that combines basic Precomputed Radiance Transfer [Sloan2002] and a modified Shading Cache [Tole2002] using OSG for realtime rendering as well as Adian Egli's generously contributed kdtree for raytracing. You have often spoken of an osgForge site that you wanted to set up and which would allow hosting of different OSG-related projects. Will that site see the light of day anytime soon? It would be a nice place where my project could live and others could contribute to it if they find it useful. And in a more general sense, I think it would be very cool to group all the cool projects that people want to make available to others, and it would encourage others to use them and contribute to them as was done with OSG itself, but on a smaller and even more distributed scale. Otherwise I can always make a googlecode project or something, or even just open up my local SVN for read-only access, but I'd prefer to host it somewhere where potential problems with my own computer infrastructure would not affect it, and an osgForge would provide some nice visibility too. :-) Don't be afraid of googlecode--it's quite awesome... If I can help make osgForge a reality, let me know. Thanks, J-S [Sloan2002] Peter-Pike Sloan, Jan Kautz and John Snyder Precomputed Radiance Transfer for Real-Time Rendering in Dynamic, Low-Frequency Lighting Environments [Tole2002] Parag Tole, Fabio Pellacini, Bruce Walter and Donald P. Greenberg Interactive Global Illumination in Dynamic Scenes ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem building OpenSceneGraph on CentOS
On Wed, 2008-05-07 at 14:05 -0400, Jean-Sébastien Guay wrote: Hello Srikanth, I am getting this error while building a plugin.May I know what is this CURL plugin can I turn it off ? You need the libcurl development libraries. Perhaps there's an option in CMake to disable building libcurl, I don't know. I think he has the devel libs (do: rpm -qa | grep curl) but that they're just too old. The rpm query will tell us more; it my be in order to add some CURL version checking to the CMake build infrastructure. This is my third post to the community and let me see If I get a reply. You got an answer about your PostScript and mouse wheel question, and for the one with subject filling colors into drawn objects, Robert asked you separate your questions into distinct posts, which I think is a reasonable request given they are pretty much unrelated. The community here is excellent, you just have to help us help you :-) Much nicer than how I would have worded it... *grumble* (others would post a link to ESR's smart questions page, but I find it overkill - I trust you understand the points I make above) Hope this helps, J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgDB::FieldReaderIterator
I'm using osgDB::FieldReaderIterator (the parent class to osgDB::Input, which you may have used in a plugin if you've developed one) to parse some style (kinda' like CSS) data for osgWidget. The API is pretty straightforward, and there are lots of examples of it's usage throughout OSG, but what I can't seem to find is a way to ask the FRI to advance the remainder of the line. Is there a way to accomplish this using this class? I'd do it myself, but the osgDB::Field object seems to handle this internally. Would this be a candidate for patch/submission, or am I using the API wrong? The only reason it's important to me is because I'd like to provide some parsing failure information to the user, but as far as I can tell the API seems to be designed to just silently ignore such things (and indeed, this is working perfectly for me. :)) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on how to add timeline control to osg window
This is quite possible in osgWidget; if you can give me more info, I can whip up an example for you... On Wed, 2008-05-07 at 16:20 -0400, [EMAIL PROTECTED] wrote: Greetings All - I was wondering if anyone could point me in the right direction (what tools, etc to use). I need to take an osg window, plot some points on a coordinate system based on time. I need a sliding control that can manually adjust the time frame of my sequence. Just curious what tools should I use? I was reading about wxwidgets, but I didn't really see any osg examples of using them. Just wondering if anyone would have any thoughts? Thanks, Curt __ Plan your next roadtrip with MapQuest.com: America's #1 Mapping Site. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on how to add timeline control to osg window
I'll get an example together in the next day or two using osgWidget to see if it's capable of doing what you want. In the meantime, feel free to check out the source (osgWidget is still ALPHA software): http://osgwidget.googlecode.com On Wed, 2008-05-07 at 17:10 -0400, [EMAIL PROTECTED] wrote: Hi Jeremy - I was thinking of basically a slider control, with maybe some forward/backward/pause buttons (similar to a 'CD' player type control). My application would just have an internal set of points that I can plot over time. When you press play, the app just plots points based on a timer, you could pause, rewind, etc. I'm sure it pretty simple, but being an osg newbie - I can't see the forest for the trees :) Thanks for the help! Curt if you can give me more info, I can -Original Message- From: Jeremy Moles [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Wed, 7 May 2008 3:20 pm Subject: Re: [osg-users] Advice on how to add timeline control to osg window This is quite possible in osgWidget; if you can give me more info, I can whip up an example for you... On Wed, 2008-05-07 at 16:20 -0400, [EMAIL PROTECTED] wrote: Greetings All - I was wondering if anyone could point me in the right direction (what tools, etc to use). I need to take an osg window, plot some points on a coordinate system based on time. I need a sliding control that can manually adjust the time frame of my sequence. Just curious what tools should I use? I was reading about wxwidgets, but I didn't really see any osg examples of using them. Just wondering if anyone would have any thoughts? Thanks, Curt __ Plan your next roadtrip with MapQuest.com: America's #1 Mapping Site. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ Plan your next roadtrip with MapQuest.com: America's #1 Mapping Site. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDB::FieldReaderIterator
On Thu, 2008-05-08 at 09:26 +0100, Robert Osfield wrote:
Hi Jeremy,
I don't often get questions about osgDB::FieldReaderIterator :-)
This particular help class is one I wrote 6 or 7 years ago in support
of the .osg format,
and haven't actually touched it at all since. If I were to rewrite it
today it'd probably be
quite different. But mostly it does it job just fine, so it ain't
broke don't fix it...
So in your case you want means for iterating to the end of the line,
something I don't recall having added support for. Adding it will
probably require something like adding a line number of the Field
object, and tracking of returns internally and incrementing the line
count as fields are read. Once you have the line number it'd be easy
to keep reading till the end of the line.
I found a way to kinda' fudge this using the current API without it
being a piece of horrible code. For now, this will do. I may take a
closer look at some of the parsing stuff you introduce from VPB though
when the time comes and possibly convert. :)
W.r.t usage, the .osg ascii reading support is geared up around use of
or { } blocks to deliminate start and end of parameters, in much
the same way as C++ is handled, with returns not directly affecting
things. So it might be that you could take the same approach. Could
you provide an example of the types of ascii file data that you want
to parse.
I purposefully kept the syntax consistent with the rest of the OSG. For
example, here's an example stylesheet:
-
widget {
color 255 255 255 255
padding-left 20
}
widget.myClass {
layer TOP
}
-
...where all widget objects would have the first style element applied
and all widgets with the explicit myClass style attribute set would
receive the former _and_ the latter. Really, I think the only problem I
was having was that I was trying to keep track of what line I was on,
and that's really not necessary. The API easily skips errors, so I've
just decided to mostly inherit that behavior as well.
I'll just have to make sure the style syntax is well documented. :)
On a slightly different, but related topic, VPB has a number of extra
helper classes for serialization of parameters, these are ones that I
do plan on integrating with core OSG. They won't solve the particular
problem you wish to tackle, but they can certainly help with
streamlining of parsing code.
Robert.
On Wed, May 7, 2008 at 7:49 PM, Jeremy Moles [EMAIL PROTECTED] wrote:
I'm using osgDB::FieldReaderIterator (the parent class to osgDB::Input,
which you may have used in a plugin if you've developed one) to parse
some style (kinda' like CSS) data for osgWidget. The API is pretty
straightforward, and there are lots of examples of it's usage throughout
OSG, but what I can't seem to find is a way to ask the FRI to advance
the remainder of the line.
Is there a way to accomplish this using this class? I'd do it myself,
but the osgDB::Field object seems to handle this internally.
Would this be a candidate for patch/submission, or am I using the API
wrong? The only reason it's important to me is because I'd like to
provide some parsing failure information to the user, but as far as I
can tell the API seems to be designed to just silently ignore such
things (and indeed, this is working perfectly for me. :))
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with osgviewerGTK example
On Fri, 2008-05-09 at 13:30 +0200, Martin Großer wrote: Hello, when I use the osgviewerGTK, I see a very simplistic model and it is black. For example I used the cessna.osg file and I made a picture. I have attach the picture to this mail. What could be the problem? Does this happen on all viewers, or just the GTK one? Also, what happens when you toggle on the 60 FPS button? Cheers, Martin ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [Blender and OSG]
No one except the Blender developers know what a .blend file is, and even they can't really even explain much about it. I've tried many times in the past to wrap my head around its binary format, but it's seriously the very definition of moving target. Besides, if you asked the Blender developers in IRC, they'd say trying to load a .blend file in your engine is really a bad idea (I've been the recipient of this kind of scolding :)). Your best bet is to use the .osg exporter, which works quite well. Even better, you could get a copy of the modified one in the AnimTK project, which has a few small bug fixes here and there that will (eventually) get propagated back to the main one. On Tue, 2008-05-13 at 16:57 +0200, Jean-Baptiste Authesserre wrote: Hi, I would like to use blender to create my 3D models. Is that possible to use blender files .blend with osg? I compiled by myself osg by using Cmake for the configuration of the Visual studio project. I found no mention about blender during this configuration step. After the compilation, there exist in the generated plugin folder the file osgdb_3ds.dll, which I suppose allow me to use 3DSMAX file. But I don't find anything about blender. Could anybody help me? Best regards, Jean-Baptiste. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget 0.1.8 (pre-merge)
On Tue, 2008-05-13 at 17:26 +0200, Mario Valle wrote: Thanks Jeremy for your work! Trying osgwidgetinput I receive the following warnings on Linux with latest SVN. At least one of them could be stopped if you could provide the missing font Calibri1.ttf . Is it possible? Ciao! mario This is a Microsoft font. :( Perhaps I should consolidate all of these examples to use a Linux front that I CAN distribute or perhaps just the arial font included in the OpenSceneGraph-Data project. At any rate, my rampant and unpredictable use of fonts is just a way for me to try and mix things up; please feel free to change that font/arial.ttf... Obviously, issues such as these can't exist when I do the submission, so it's good to bring up! I'll add it on the TODO on the website... isone /local/OSG/osgwidget-read-only/examples/osgwidgetinput ./osgwidgetinput Warning: font file fonts/Calibri1.ttf not found. Warning: font file fonts/Calibri1.ttf not found. osgWidget: Widget [Label_Row0] was asked to set it's width to 50, but the minimum width is 80. Warning: font file fonts/Calibri1.ttf not found. Warning: font file fonts/Calibri1.ttf not found. osgWidget: Widget [Label_Row1] was asked to set it's width to 50, but the minimum width is 80. Warning: font file fonts/Calibri1.ttf not found. Warning: font file fonts/Calibri1.ttf not found. osgWidget: Widget [Label_Row2] was asked to set it's width to 50, but the minimum width is 80. Warning: font file fonts/Calibri1.ttf not found. osgWidget: Widget [Widget_1] was asked to set it's height to 18, but the minimum height is 44. Warning: font file fonts/Calibri1.ttf not found. osgWidget: Window [frame] couldn't find the Widget [Input_Row0] in it's object list. osgWidget: Input is disabled until someone can help me understand how to use osgText; sorry... osgWidget: Input is disabled until someone can help me understand how to use osgText; sorry... osgWidget: Window [frame] couldn't find the Widget [Input_Row0] in it's object list. osgWidget: MousePush @ Window: table osgWidget: MousePush @ Window: table osgWidget: MousePush @ Window: table osgWidget: Window [frame] couldn't find the Widget [Input_Row0] in it's object list. osgWidget: Window [frame] couldn't find the Widget [Input_Row0] in it's object list. osgWidget: Window [frame] couldn't find the Widget [Input_Row0] in it's object list. osgWidget: x: y: z: osgWidget: Window [frame] couldn't find the Widget [Widget_2] in it's object list. osgWidget: x: y: z: osgWidget: Window [frame] couldn't find the Widget [Widget_2] in it's object list. Jeremy Moles wrote: I've put the (hopefully!) final version of a separate osgWidget up on the googlecode site: http://osgwidget.googlecode.com This means that I feel like I'm getting closer to the point where it would make sense to submit osgWidget to Robert to see how he feels about inclusion into the main trunk, with ongoing development there instead. This will expose far more eyeballs to osgWidget's codebase, which can only be good as development continues. The next version (I'll call 0.2.0 for now) will be the one I submit, and I'm going to construct a serious TODO list of items on the website project page of things I want to accomplish prior to this. I can't say how long this will take, but hopefully no longer than about two weeks or so... This also means I'll probably make a few posts within the next two weeks asking questions regarding some outstanding issues, soliciting design opinions, etc. I only even mention this so that folks don't think I'm spamming the lists. :) Keep in mind that even if Robert is feeling brave enough to allow this code to sneak in, it won't nearly be feature complete. The goal, however, isn't to provide a final version but to expose more people and hopefully expose more bugs/flaws. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget 0.1.8 (pre-merge)
On Tue, 2008-05-13 at 17:49 +0200, Thibault Genessay wrote: Hi Jeremy I've just tried to compile your code using Visual Studio 9.0 and got lots of errors that are almost all related to 'const' usage. I am sometime suspicious about Redmond compilers so I also tried to compile the code on Debian 4.0, and the errors are (hopefully) similar. Here is the output from the Linux build: [EMAIL PROTECTED]:~/prog/osgWidget-0.1.8$ make Scanning dependencies of target osgWidget [ 2%] Building CXX object CMakeFiles/osgWidget.dir/src/Box.o [ 5%] Building CXX object CMakeFiles/osgWidget.dir/src/Canvas.o [ 8%] Building CXX object CMakeFiles/osgWidget.dir/src/Frame.o /home/tibo/prog/osgWidget-0.1.8/include/osgWidget/UIObjectParent: In member function 'T* osgWidget::UIObjectParentT::_getByName(const std::string) const [with T = osgWidget::Widget]': /home/tibo/prog/osgWidget-0.1.8/include/osgWidget/UIObjectParent:76: instantiated from 'const T* osgWidget::UIObjectParentT::getByName(const std::string) const [with T = osgWidget::Widget]' /home/tibo/prog/osgWidget-0.1.8/src/Frame.cpp:109: instantiated from here /home/tibo/prog/osgWidget-0.1.8/include/osgWidget/UIObjectParent:56: error: invalid conversion from 'const osgWidget::Widget*' to 'osgWidget::Widget*' make[2]: *** [CMakeFiles/osgWidget.dir/src/Frame.o] Error 1 make[1]: *** [CMakeFiles/osgWidget.dir/all] Error 2 make: *** [all] Error 2 I'd be real interested to know what version of GCC is complaining about this. I don't see this error on Fedora 8/GCC4.1, and I've never had an e-mail about it or antyhing. The code, as far as I can tell, is perfectly valid C++. Perhaps I can come up with a workaround for this, as I really do believe it's valid C++... And Windows build: 3-- Build started: Project: osgWidget, Configuration: Debug Win32 -- 3Compiling... 3WindowManager.cpp 3.\src\WindowManager.cpp(191) : error C2440: 'initializing' : cannot convert from 'const osgWidget::Window *' to 'osgWidget::Window *' 3Conversion loses qualifiers 3.\src\WindowManager.cpp(203) : error C2440: 'initializing' : cannot convert from 'const osgWidget::Widget *' to 'osgWidget::Widget *' 3Conversion loses qualifiers 3.\src\WindowManager.cpp(333) : error C2440: 'initializing' : cannot convert from 'const osgWidget::Window *' to 'osgWidget::Window *' 3Conversion loses qualifiers [...] This is the exact same problem as above. I can definitely come up with a workaround, but if possible I'd like to see your version of GCC first if possible. :) Thibault On Tue, May 13, 2008 at 5:03 PM, Jeremy Moles [EMAIL PROTECTED] wrote: I've put the (hopefully!) final version of a separate osgWidget up on the googlecode site: http://osgwidget.googlecode.com This means that I feel like I'm getting closer to the point where it would make sense to submit osgWidget to Robert to see how he feels about inclusion into the main trunk, with ongoing development there instead. This will expose far more eyeballs to osgWidget's codebase, which can only be good as development continues. The next version (I'll call 0.2.0 for now) will be the one I submit, and I'm going to construct a serious TODO list of items on the website project page of things I want to accomplish prior to this. I can't say how long this will take, but hopefully no longer than about two weeks or so... This also means I'll probably make a few posts within the next two weeks asking questions regarding some outstanding issues, soliciting design opinions, etc. I only even mention this so that folks don't think I'm spamming the lists. :) Keep in mind that even if Robert is feeling brave enough to allow this code to sneak in, it won't nearly be feature complete. The goal, however, isn't to provide a final version but to expose more people and hopefully expose more bugs/flaws. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget 0.1.8 (pre-merge)
On Tue, 2008-05-13 at 20:28 +0200, Art Tevs wrote: Hi Jeremy, I wanted to try out your lib, but I have problems regarding to the cmake build system. First problem is, if you have osg installed not under standard directory. I have then manually to specify the cmake_include and cmake_lib paths. Yeah, this is why I recommend ccmake, because I always do this myself. Since I had intentions of this going into OSG all things going according to plan, I never really went too in-depth with making that process easier. :( maybe you could take a look into CMake build system of osgPPU, which I have tried to improve for simpler use. Examples do compiles, however I have seg faults and cannot run them. The gdb says it is somewhere on the osg side (osg::Node::setNodeMask). However since osg works fine, I assume that there are somewhere zero pointers in use.;( I am now compiling osg in debug mode, to find out what happens. Maybe I let you know later, what is the status. Yes, please! :) Even a hint might be enough... Best regards, Art P.S. Change the line with ccmake .. in README to cmake .., because this is actually what one has to call ;) --- Jeremy Moles [EMAIL PROTECTED] schrieb: I've put the (hopefully!) final version of a separate osgWidget up on the googlecode site: http://osgwidget.googlecode.com This means that I feel like I'm getting closer to the point where it would make sense to submit osgWidget to Robert to see how he feels about inclusion into the main trunk, with ongoing development there instead. This will expose far more eyeballs to osgWidget's codebase, which can only be good as development continues. The next version (I'll call 0.2.0 for now) will be the one I submit, and I'm going to construct a serious TODO list of items on the website project page of things I want to accomplish prior to this. I can't say how long this will take, but hopefully no longer than about two weeks or so... This also means I'll probably make a few posts within the next two weeks asking questions regarding some outstanding issues, soliciting design opinions, etc. I only even mention this so that folks don't think I'm spamming the lists. :) Keep in mind that even if Robert is feeling brave enough to allow this code to sneak in, it won't nearly be feature complete. The goal, however, isn't to provide a final version but to expose more people and hopefully expose more bugs/flaws. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ Gesendet von Yahoo! Mail. Dem pfiffigeren Posteingang. http://de.overview.mail.yahoo.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget 0.1.8 (pre-merge)
On Tue, 2008-05-13 at 18:44 +0200, Thibault Genessay wrote: Hi Jeremy On Tue, May 13, 2008 at 6:16 PM, Jeremy Moles [EMAIL PROTECTED] wrote: On Tue, 2008-05-13 at 17:49 +0200, Thibault Genessay wrote: Hi Jeremy I've just tried to compile your code using Visual Studio 9.0 and got lots of errors that are almost all related to 'const' usage. I am sometime suspicious about Redmond compilers so I also tried to compile the code on Debian 4.0, and the errors are (hopefully) similar. Here is the output from the Linux build: [EMAIL PROTECTED]:~/prog/osgWidget-0.1.8$ make Scanning dependencies of target osgWidget [ 2%] Building CXX object CMakeFiles/osgWidget.dir/src/Box.o [ 5%] Building CXX object CMakeFiles/osgWidget.dir/src/Canvas.o [ 8%] Building CXX object CMakeFiles/osgWidget.dir/src/Frame.o /home/tibo/prog/osgWidget-0.1.8/include/osgWidget/UIObjectParent: In member function 'T* osgWidget::UIObjectParentT::_getByName(const std::string) const [with T = osgWidget::Widget]': /home/tibo/prog/osgWidget-0.1.8/include/osgWidget/UIObjectParent:76: instantiated from 'const T* osgWidget::UIObjectParentT::getByName(const std::string) const [with T = osgWidget::Widget]' /home/tibo/prog/osgWidget-0.1.8/src/Frame.cpp:109: instantiated from here /home/tibo/prog/osgWidget-0.1.8/include/osgWidget/UIObjectParent:56: error: invalid conversion from 'const osgWidget::Widget*' to 'osgWidget::Widget*' make[2]: *** [CMakeFiles/osgWidget.dir/src/Frame.o] Error 1 make[1]: *** [CMakeFiles/osgWidget.dir/all] Error 2 make: *** [all] Error 2 I'd be real interested to know what version of GCC is complaining about this. I don't see this error on Fedora 8/GCC4.1, and I've never had an e-mail about it or antyhing. The code, as far as I can tell, is perfectly valid C++. Perhaps I can come up with a workaround for this, as I really do believe it's valid C++... And Windows build: 3-- Build started: Project: osgWidget, Configuration: Debug Win32 -- 3Compiling... 3WindowManager.cpp 3.\src\WindowManager.cpp(191) : error C2440: 'initializing' : cannot convert from 'const osgWidget::Window *' to 'osgWidget::Window *' 3Conversion loses qualifiers 3.\src\WindowManager.cpp(203) : error C2440: 'initializing' : cannot convert from 'const osgWidget::Widget *' to 'osgWidget::Widget *' 3Conversion loses qualifiers 3.\src\WindowManager.cpp(333) : error C2440: 'initializing' : cannot convert from 'const osgWidget::Window *' to 'osgWidget::Window *' 3Conversion loses qualifiers [...] This is the exact same problem as above. I can definitely come up with a workaround, but if possible I'd like to see your version of GCC first if possible. :) Strange ... I have 4.1 as well: [EMAIL PROTECTED]:~$ g++ --version g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) However, on the C++ side, I feel that there is a problem somewhere. At line 191 of WindowManager.cpp, you write Window* parent = wl-back()-getParent(); // wl is declared as 'const WidgetList* wl' Was this the only line you needed to change? Were there others? :) Which does not seem valid to me. wl is a const list that holds const pointers, which can't be casted to non-const Window*. I have tried to replace line 191 by const Window* parent = ... under Visual C++ and the error for that line went away. As far as I have looked in the sources to find the errors, both compilers seemed to be right. The fact that two completely different environments (XP SP2 + VC 9 + CMake 2.5, Debian 4 + GCC 4.1.2 + CMake 2.6) give the same errors do not look like a coincidence. But ... I'm really puzzled by this because I had successfully compiled osgWidgets-0.17 previously and I doubt all of these errors were introduced in the meantime. Regards Thibault Thibault On Tue, May 13, 2008 at 5:03 PM, Jeremy Moles [EMAIL PROTECTED] wrote: I've put the (hopefully!) final version of a separate osgWidget up on the googlecode site: http://osgwidget.googlecode.com This means that I feel like I'm getting closer to the point where it would make sense to submit osgWidget to Robert to see how he feels about inclusion into the main trunk, with ongoing development there instead. This will expose far more eyeballs to osgWidget's codebase, which can only be good as development continues. The next version (I'll call 0.2.0 for now) will be the one I submit, and I'm going to construct a serious TODO list of items on the website project page of things I want to accomplish prior to this. I can't say how long this will take, but hopefully no longer than about two weeks or so... This also means I'll probably make a few posts
Re: [osg-users] osgWidget 0.1.8 (pre-merge)
On Wed, 2008-05-14 at 08:57 +0200, Thibault Genessay wrote:
Hi Jeremy
Window* parent = wl-back()-getParent(); // wl is declared as 'const
WidgetList* wl'
Was this the only line you needed to change? Were there others? :)
If it had only been as easy as modifying 1 line, I would have sent you
a patch rather than complaining :)
I could not get the beast compiling because in so many places the same
programming logic is used. If I remove constness from somewhere, it
propagates upwards from caller to caller until everything becomes non
const ...
I still don't understand how it can work with you guys ... Typical
things that seem wrong to me are:
in src/UIObjectParent:54
object_type* _getByName(const std::string name) const {
for(ConstIterator i = begin(); i != end(); i++) {
if(i-valid() i-get()-getName() == name) return
i-get();
}
return 0;
}
A const method doing a const-iteration on a container cannot return a
non const pointer to an element of that container, can it ?
The prototype for ref_ptr::get looks like this:
T* get() const { return _ptr; }
It's a const method that returns a non-const pointer. I've done a bit of
research, and this does appear to be something some compilers catch and
some don't, so I'm not sure how OSG builds for any of us if we really
adhering to some strict checking.
In the above example, I imagine it works because while ref_ptr::get()
returns a non-const pointer, the ConstIterator never calls a non-const
method of the ref_ptr class.
Perhaps a real C++ guru can shed some light here...
Somewhere else:
void Window::_setFocused(Widget* widget) {
[...]
}
bool Window::setFocused(const Widget* widget) {
ConstIterator i = std::find(begin(), end(), widget);
_setFocused(i-get());
}
// i-get() returns a const Widget* that cannot be passed as argument
to _setFocused(), can it ?
I'm starting to feel strange, as if I had seen an alien and the FBI in
my garden and the government had told me that nothing had happened.
Nothing. So would have had my neighbours, making me feel alone and not
so sure that I had actually seen anything. :)
I am as well. :)
I'm going to install Fedora 9 (which will give me GCC4.2), and I'm going
to google for some additional strict-checking options for GCC. Perhaps I
can find a way to reproduce this and get it squashed...
I've got VC++9 installed on my Windows partition, I've just never been
able to get OSG to build at all there. However, there have been lots of
threads recently on the subject, so perhaps now is the time to spend an
afternoon doing it...
At any rate, thanks for the info!
Regards
Thibault
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Operating Systems + Applications - Application Systems
On Fri, 2008-05-16 at 22:46 +0200, Zoltán wrote: Robert Osfield wrote on Friday 16 May 2008: Or course PC hardware is far more varied than Console is, but thankfully OpenGL and a decent OS can hide much of these variants for causing us too much concern. Robert, you forget one particular piece of open-source stuff, or more specifically Linux stuff: proprietary drivers and GPL !!! Most 3D hardware works rather well in Linux, but only with binary drivers and after some heavy tweaking. I've recently tried the latest Mandrive 2008 spring LiveCD distribution, and it was able to boot my computer (ThinkPad T43 with ATI X300) with full 3D support out of the box, but it was the first time I've seen that. I've also read about a LiveCD distribution that provided 3D proprietary drivers out of the box for most hardware and that the GNU people attacked, and obliged to retract. That was because a distribution doesn't have the right to provide closed-source drivers in a GNU environment, and it is only possible if it is the user's *OWN PERSONAL* choice outside the GNU framework to do so. (I hope you understand what I try to explain, I'm no specialist in the area) There's simply no way this is true; period. I imagine there are many more details being left out--perhaps you could provide some links to reports or documentation that led you to believe this? What is possible, however, is that the providers of the proprietary drivers do not allow distribution of their code in a bundled way without some kind of special permission... So for a LiveCD with OSG and some 3D application (if I understand you correctly) to work seamlessly for JoeSixPack there is a long way to go. And it's not only a technical problem (as Mandriva demonstrates) but also a legal one. I don't know how Mandriva gets around the legal hurdles (lack of European software patents ?) The purpose of this email is to throw this possibility out there, and to get feedback from OSG users who might find such an means of distribution useful. There are members of the community far better placed to actual go ahead and implement such a system too so I'd be nice to hear from guys with more knowledge on the OS side. There are already tools for creating Live CD's, I haven't played with them yet, but perhaps in a few years I'll have time to... If we're at it, I suggest LinuxFromScratch (LFS): http://www.linuxfromscratch.org/ I like your way of thinking, but I fear there are other problems - non technical - to resolve. Zoltán ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgWidget Design Advice
Hello all! Allow me to talk briefly about osgWidget's current design and perhaps how I can change it for the better. A number of people over the last few months have asked me why the WindowManager object requires an osgViewer::View* to be created. This is an interesting question, and it segues into something possibly more complicated, and which potentially demonstrates my lack of understanding of some things related to OSG. :) To summarize, a WindowManager object in osgWidget is derived from osg::Switch, and its purpose is to position and layer various Window objects which are added to it. It does this in a kind of virtual space--that is to say, it has no awareness of how it will be viewed, and I leave that aspect up to the user. Windows in osgWidget are derived from osg::MatrixTransform, so it is quite simple to position and size these objects in a virtual space. However, as I mentioned earlier, when created a WindowManager must have access to an osgViewer::View* so that it can call the computeInteresections() method on this pointer and perform proper picking. This raises an interesting design question: what exactly is (or should be) the relationship between a WindowManager and an osg::Camera? There certainly is SOME relationship, but whether or not I am properly utilizing it in osgWidget remains to be seen. If any of you have used osgWidget you may be familiar with the following convenience method: osgWidget::WindowManager::createParentOrthoCamera() What this member/method does is creates an orthographic 2D camera, adds the this pointer as it's first child, and returns the newly created Camera. This is a quick way to put the WindowManager object in a state where it can be seen and behaves as expected, but I fear I may have this all only accidentally working. My question, then, is to the OSG Gurus: if you were designing osgWidget, how would you model this relationship between the topmost osgWidget manager object and the Camera to which it should be attached? Would you use an osgViewer::View* like I do to perform picking, or would you interface directly with the Camera and perform picking that way? If so, the question of WindowManager-Camera relationship becomes even more important. Furthermore, how would you handle 3D GUI objects, which can certainly be added to a WindowManager's virtual space, but will appear wildly differently depending on whether the object is viewed through an orthographic or perspective camera? (Please forgive me if I'm using some wrong terminology here, I hope I get the idea across!) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget Design Advice
On Mon, 2008-11-24 at 23:22 -0500, Jean-Sébastien Guay wrote: Hi Jeremy, Why does the WindowManager have to know anything about cameras? I have the same question, but with different results: unless I've missed something in your description, why does anyone need to know about the camera? If you get your click events (which you act upon to get intersections) through an event handler, then you can just get an osg::View* with aa.asView(), which then has a camera. No one really needs to hold on to a camera pointer. I would definitely go with calculating intersections directly through osgUtil::IntersectionVisitor. You can use the constructor that takes one of the WINDOW, PROJECTION, VIEW and MODEL enum values to easily construct the right intersector. It should even work for 3D widgets in space... space ... space ... :-) As for creating an ortho viewport, perhaps you can return an osg::Camera with the right setup, and the user can then assign that to their viewer/view/slave camera/scenegraph/whatever. It would be more general. That way you can remove the dependency between osgWidget and osgViewer (not sure if that's the goal here, but if intersections was the only thing that forced that dependency, I'd definitely remove it). Yeah, removing this dependency is definitely something I'd like to do, and computeIntersections is the only things I use. Anyways, like the others who replied I don't really know the internals of osgWidget, so perhaps there's something I've overlooked, but that's how I see it at first glance. Hope this helps, J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget Design Advice
On Tue, 2008-11-25 at 10:05 -0500, Max Bandazian wrote: Jeremy, Having used osgWidget extensively, I second what everyone has said I would definitely be interested most in the opinions of people who have used osgWidget most. :) above, that the input processing/picking ought to be factored out of the WindowManager into a separate class. osgWidget is a nice contribution to osg, but it does have a lot of instances like this where modularity could be improved. Input processing/picking is a tricky thing, and it would be great to have an easy setup for swapping in my own input handler; for instance, by default the topmost picked widget is selected, but I might want to pick through pixels that are textured transparent. This is not a bad idea, but I'm not sure I fully understand how you want them divorced. You're absolutely right that there is currently no easy way to pick through a transparent pixel. Perhaps the answer here is not to break it apart, but make creating derived WindowManagers easier? Since you're in a refactoring mood, I also want to mention that the biggest thing you could do to improve osgWidget is get rid of all uses of the friend keyword. It's not good in a toolkit, especially an alpha version toolkit, as it is mostly impossible to extend/override/bugfix the existing stuff by inheritance. For my own project, I needed to inherit from some of the widget classes and had to build my own friendless version as a result. This would be easy to get rid of, and something I could do quickly. I can make a more extensive list of ''suggested improvements'' if you want :) Please do. :) The results of this discussion thread will determine if I am way over my head or not with osgWidget. It may turn out that I've tackled a project much larger than my understanding, and need to scrap it entirely. :( - Max Bandazian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] aa
On Wed, 2008-12-03 at 21:09 +0100, Sukender wrote: 0xff (=16777215 = b = ...) PS: Morse code is not used anymore! PS2: When we'll reach zzz...zzz, then we'll know we're at least 26 fools :) Whatver, I'm not a fool. Shsh... Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Wed, 03 Dec 2008 21:02:57 +0100, Tomlinson, Gordon [EMAIL PROTECTED] a écrit: E or . . . . . :) Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Bosse' Sent: Wednesday, December 03, 2008 2:19 PM To: OpenSceneGraph Users Subject: Re: [osg-users] aa On Wed, Dec 3, 2008 at 4:37 AM, Ümit Uzun [EMAIL PROTECTED] wrote: I have though to send bbb before Robert but then think it might be seen foolish :) But Robert seems braver :) Congratulations! And it's my turn :) ccc 2008/12/3 Robert Osfield [EMAIL PROTECTED] On Wed, Dec 3, 2008 at 8:05 AM, Malcom Poiter [EMAIL PROTECTED] wrote: aaa ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph .org -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org -- It is only necessary to make war with five things: with the maladies of the body, with the ignorances of the mind, with the passions of the body, with the seditions of the city, with the discords of families. - Tacitus The desire for safety stands against every great and noble enterprise. - Tacitus Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin Numquam ponenda est pluralitas sine necessitate. - William of Ockham ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] aa
On Wed, 2008-12-03 at 15:15 -0500, Jeremy Moles wrote: On Wed, 2008-12-03 at 21:09 +0100, Sukender wrote: 0xff (=16777215 = b = ...) PS: Morse code is not used anymore! PS2: When we'll reach zzz...zzz, then we'll know we're at least 26 fools :) Whatver, I'm not a fool. Shsh... Oh no, wait, wait. I just went backwards from F. That's no ood... Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Wed, 03 Dec 2008 21:02:57 +0100, Tomlinson, Gordon [EMAIL PROTECTED] a écrit: E or . . . . . :) Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Bosse' Sent: Wednesday, December 03, 2008 2:19 PM To: OpenSceneGraph Users Subject: Re: [osg-users] aa On Wed, Dec 3, 2008 at 4:37 AM, Ümit Uzun [EMAIL PROTECTED] wrote: I have though to send bbb before Robert but then think it might be seen foolish :) But Robert seems braver :) Congratulations! And it's my turn :) ccc 2008/12/3 Robert Osfield [EMAIL PROTECTED] On Wed, Dec 3, 2008 at 8:05 AM, Malcom Poiter [EMAIL PROTECTED] wrote: aaa ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph .org -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org -- It is only necessary to make war with five things: with the maladies of the body, with the ignorances of the mind, with the passions of the body, with the seditions of the city, with the discords of families. - Tacitus The desire for safety stands against every great and noble enterprise. - Tacitus Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin Numquam ponenda est pluralitas sine necessitate. - William of Ockham ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] High resolution screencast
Not trying to hijack this thread--and I can't really read it all for now because I'm still fighting off lots of complications from a recent oral surgery--but what you want is called bugle. I used it to make all of the old osgWidget and osgPango videos and it works like a charm. What it does is LD_PRELOAD's glSwap() or whatever and replaces it with a version that shimmies off data to ffmpeg for encoding. Simple, clean, and easy for basic usage. On Thu, 2008-12-18 at 20:38 +0100, Simon Loic wrote: Hi, I apology in advance if this thread have been heavily answered before (if so just tell where I can find the solution). Still I would like to know the different alternative (the good ones) to record a video of my scene. So far I was using an external tool for screenCast (called istanbul). But I'm not satisfied by this because when my scene is very complex, my osg based application is lagging and this leads to a poor quality of th video. I'm especially interested if there is a way to create an RecordCameraPathHandler to record a path, and then instead of saving it as a .path file compute the video in a batch mode. By batch mode I mean that the creation of the video doesn't need to be real time. In that way I could hopefully control the lag effects and eventually the resolution of the video. Sincerely, -- Loïc Simon ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] High resolution screencast
On Fri, 2009-01-09 at 19:33 +0100, Simon Loic wrote:
Ok forget about it it was a problem of -fPic flag in the compilation
of some libraries.
The next step is to make osg framerate constant in order to get smooth
videos. If I undertood well what was said before this consists in
rewriting the Mainloop of the viewer. I'll try this soon.
It's much easier if you're using an NVidia card! :) Here are two bash
functions I wrote to help:
# Run an OpenGL application with antialiasing.
function __fsaa() {
if [ -z ${*} ]; then
echo -e usage: fsaa NUM CMDLINE\n
echo -e \t0 = FSAA disabled
echo -e \t1 = 2x Bilinear Multisampling
echo -e \t2 = 2x Quincunx Multisampling
echo -e \t3 = FSAA disabled
echo -e \t4 = 4x Bilinear Multisampling
echo -e \t5 = 4x Gaussian Multisampling
echo -e \t6 = 2x Bilinear Multisampling 4x SS
echo -e \t7 = 4x Bilinear Multisampling 4x SS
echo -e \t8 = 4x Bilinear Multisampling 2x SS\n
return 1
else
local MODE=${1}
shift 1
eval __GL_FSAA_MODE=${MODE} ${*}
fi
}
# Run an OpenGL application with vsync enabled.
function __glsync() {
eval __GL_SYNC_TO_VBLANK=1 ${*}
}
...
Once you've added these to your bashrc, you can do something like this:
# __glsync osgviewer
...or...
# __fsaa 4 __glsync osgviewer
The general idea is to export the __GL_* variables properly. :)
Thanks once again.
On Thu, Jan 8, 2009 at 10:56 AM, Simon Loic simon1l...@gmail.com
wrote:
Hi, I'm back at work and I can give you the details.
The first problem I had was at compile time. I think it was
linked with conflicting definitions. Here is the error
message.
/bin/mkdir -p bc/gl
perl ./gengl/gengl.perl --mode=alias /usr/include/GL/gl.h
/usr/include/GL/glx.h /usr/include/GL/glext.h
/usr/include/GL/glxext.h bc/gl/alias.bc
glFramebufferTextureLayerEXT is defined in both
GL_NV_geometry_program4 and GL_EXT_texture_array
at ./gengl/gengl.perl line 436, H line 10154.
To solve it I did something quite ugly : I commented the
mentioned line 436 of gengl/gengl.perl. After that It
compiles but I looking forward a better fix.
The second problem I get is the more important. The bugle
filterset associated with screen capture is not recognised.
I get the following warning :
warning: ignoring unknown filter-set screenshot
BTW, Im using the following command :
BUGLE_CHAIN=video LD_PRELOAD=libbugle.so my_application
with the following chain:
# Captures a video file.
chain video
{
# Press C-V to start and to stop recording. By removing
the inactive
# tag, recording will start immediately.
filterset screenshot C-V inactive
{
video yes
filename bugle.avi
# You can in theory use any codec supported by ffmpeg
codec mpeg4
# Roughly DVD size, although no high quality options
are set
bitrate 750
# By default, a frame is captured every 30th of a
second, with
# frames skipped or duplicated as necessary. Uncomment
this
# line to instead capture every frame exactly once to
the
# output.
# allframes yes
# Control the encoding latency. A higher latency may
give
# better throughput, at the expense of more memory.
# lag 1
}
}
Just so you know, here is the recap of the configure script
call (it may help):
Configuration:
libavcodec: yes
readline: yes
GUI: yes (with OpenGL)
X event interception: yes
Thanks very much.
On Wed, Jan 7, 2009 at 11:38 PM, Simon Loic
simon1l...@gmail.com wrote:
I tried it but I encountered few problems. I will send
you the detailed tomorrow. Still thanks for the tip.
On Tue, Jan 6, 2009 at 5:40 PM, Jeremy Moles
jer...@emperorlinux.com wrote:
Not trying to hijack this thread--and I can't
really read it all for now
[osg-users] osgWidget Design Though (Input Events)
In osgWidget's current design, Widgets are notified of events such as mouseOver by a single ViewerEventHandler object that traverses a given root node and determines (or tries to :)) what kind of thing is going on. When I originally wrote this part of osgWidget, such was the limit of my knowldege... However, I would like to move to a more divorced system, in which each Drawable (Widget) or Node (Window) can use special UpdateCallback and NodeCallback objects so that they can simply subscribe to the events they're interested in. What I'm looking for are some ideas as to how I could best accomplish this. One possibility is that I could keep the osgWidget::ViewerEventHandlers that I currently have (MouseHandler, KeyboarHandler, etc.) except than instead of having them call the mouseOver methods on the Widgets directly they would simply set various state variables (mouse position, etc.) that the user could later query in their on NodeCallback or UpdateCallback functions. Does this make sense? Is this even a worthy endeavor? I get a lot of questions about how osgWidget marries the WindowManager+Event mechanism and the widgets it manages, so I'm looking for ways to break that up. The general idea is that I really want to use the OSG update traversal more, since right now I basically just have one object (the various ViewerEventHandlers) doing EVERYTHING on every object during their own update phase. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgwidgetscrolled example
On Wed, 2009-01-21 at 09:16 -0700, Brad Huber wrote: When I run the osgwidgetsrolled example, the window frame / theme is completely screwed up. I can still control the borders and corners with the mouse but they don’t render properly. It seems to be finding the theme .pngs just fine but just doesn’t display them properly. I'll check this out ASAP. I have OSG 2.7.8. Anyone having/not having this problem? Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Blender osgAnimation Issue
On Mon, 2009-01-26 at 19:12 -0800, Ryan Morris wrote: Hoping someone can help me out here, I think I'm missing something in Blender, I export my animations and I get TransformVertexFunctor::UniqBoneSetVertexSet no bones found when I load them. Any thoughts? -Russ There are exactly 1,323,239 ways a Blender file can be constructed improperly resulting in a bad state for export. We do as much as we can in the exporter to accommodate for this, but Blender is HUGE and the API leaves MUCH to be desired in terms of predictability. The bottom line is: you need to provide your .blend file before either Cedric or myself can help. :) osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Development plan for imminent stable OSG-2.8
On Tue, 2009-01-27 at 15:16 +, Art Tevs wrote: Hi Robert, Robert Osfield wrote: My experiences were from nearly 10 years ago now.. But issues are the same. Fixing bugs is very much a social activity, in as much as it's the fixing bugs almost always requires a two way dialogue between the people able to reproduce the bug and those engaged in try to fix it. Facilitating the two way dialogue is absolutely the most important part of any bug resolution scheme - which is why I've always focused on osg-users as the route for bug resolution. I think using a ticket system as already providid by the trac enviornment you are using for the project is the way one should go to make the project more flexible and younger. Look, the osg project is not a small project anymore and the community is continuosly growing. Using mailing lists only doesn't make all the users happy. And I still think that this kind of support/community is outdated. There exists a lot of capabilities to handle big projects well. Forums, Tickets and Wikis are such systems. We are happy to have a Wiki and a Forum now and ticket system would just make the whole project more flexible and better supported than now. I'm confused by this thread somewhat--what exactly is going on? Is OSG adopting some external management software for bug tracking and what not, or are we discussing the possibility thereof? It could even reduce your workload, because users would assigned tickets to themself and help other users without your intronvention. I understand that it is hard to give away a control to more dezentralized way, however for a such big project as osg it is the way to go in the future, I think. Come on, you will still stay the big boss/president of the osg community ;) Users/Developers/Contributors could register on the trac system with their own usernames. Then whenever a new ticket or feature request is posted somebody who thinks he is able to manage the bug, could assign the current ticket to himself. Peoples visiting the ticket system are able then to trace the bug resolution process and could see who is currently responsible for writing a solution. Even more as we have discussed in another thread (Ideas for osg 3.0) ticket system/trac environment could be setted up in a hierarchical way, so that there will be a hierarchy of contributors/maintainers of the project. When we split up osg to main core and node kit suites, there could be categories in the ticket system handling only about the node kits and the maintainer responsible for his node kit will do the managing work. I think this is the way we have to go, instead of managing bugs on a wiki page. Wiki pages would produce more work because of persistent mirroring of real osg state on the wiki page. Best regards, art -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5264#5264 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Development plan for imminent stable OSG-2.8
On Tue, 2009-01-27 at 15:51 +, Robert Osfield wrote: Hi Jeremy, On Tue, Jan 27, 2009 at 3:40 PM, Jeremy Moles jer...@emperorlinux.com wrote: I'm confused by this thread somewhat--what exactly is going on? Is OSG adopting some external management software for bug tracking and what not, or are we discussing the possibility thereof? It's just ended up being another me-too thread... lots of suggestions, little action... Nothing is happening on introducing new systems. For OSG-2.8 we'll stick with osg-users for reporting bugs and resolve them as usual, and posting details on these bugs and their resolution on the usual BugResolution page. Once OSG-2.8 we can discuss the possibility of introducing an formal system for issue tracking. Job now is to getting everything ready for OSG-2.8 and make it as best we can. Okay, cool. :) I get about 1000 lines worth of warnings when I build OSG with: -W -Wall ...which is troublesome, because it prevents me from using those arguments in my own projects because of the warnings in OSG headers. I'd like to fix this (and have brought it up in the past), but it doesn't make sense to submit 50 or 60 full files for one-line fixes. Any ideas on this? Again, I can fix it myself--the question is, do you trust me to do it? :) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Anti-Grain and OpenSceneGraph
On Tue, 2009-01-27 at 11:06 -0500, Kurt Sierens wrote: Has anyone used the Anti-Grain library in OpenSceneGraph? I would like to get a better looking text display than the osgText node kit does. If you're using Linux, you need to help me with osgPango. :) I have this same goal, and you can find more info (and screenshots) here: http://osgpango.googlecode.com Technically, Pango works on Windows (the Clutter guys use it and it's included in Gimp for Windows), but I've never done it personally so I can't comment. I'm a text display whore myself, so I will settle for absolutely nothing less than near-pixel-perfect display in my own projects. :) Some folks just don't care, but bad font quality is a deal-breaker for me. http://www.antigrain.com/index.html Thanks, Kurt __ Windows Live™ Hotmail®…more than just e-mail. See how it works. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Anti-Grain and OpenSceneGraph
On Tue, 2009-01-27 at 18:33 -0500, Kurt Sierens wrote: Jeremy, I was looking at your osgPango node kit and would actually love to use it, but what else would be required? We are ported to Windows and will also need to support Mac, not Linux or Unix at this point. We are pretty fussy about the entire user experience and the current osgText implementation gives a rather chunky result at times. I'm headed out the door now, so I'll respond more tomorrow. :) Useless, I know. And yes, osgText is horrid if you CARE about font quality, but we appear to be the minority. Date: Tue, 27 Jan 2009 11:17:11 -0500 From: Jeremy Moles jer...@emperorlinux.com Subject: Re: [osg-users] Anti-Grain and OpenSceneGraph To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: 1233073031.3353.40.ca...@dhcp196.emperorlinux.com Content-Type: text/plain; charset=UTF-8 On Tue, 2009-01-27 at 11:06 -0500, Kurt Sierens wrote: Has anyone used the Anti-Grain library in OpenSceneGraph? I would like to get a better looking text display than the osgText node kit does. If you're using Linux, you need to help me with osgPango. :) I have this same goal, and you can find more info (and screenshots) here: http://osgpango.googlecode.com Technically, Pango works on Windows (the Clutter guys use it and it's included in Gimp for Windows), but I've never done it personally so I can't comment. I'm a text display whore myself, so I will settle for absolutely nothing less than near-pixel-perfect display in my own projects. :) Some folks just don't care, but bad font quality is a deal-breaker for me. http://www.antigrain.com/index.html Thanks, Kurt __ Windows Live? Hotmail??more than just e-mail. See how it works. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ Windows Live™: E-mail. Chat. Share. Get more ways to connect. See how it works. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Anti-Grain and OpenSceneGraph
On Tue, 2009-01-27 at 18:58 -0500, Jeremy Moles wrote: On Tue, 2009-01-27 at 18:33 -0500, Kurt Sierens wrote: Jeremy, I was looking at your osgPango node kit and would actually love to use it, but what else would be required? We are ported to Windows and will also need to support Mac, not Linux or Unix at this point. We are pretty fussy about the entire user experience and the current osgText implementation gives a rather chunky result at times. I'm headed out the door now, so I'll respond more tomorrow. :) Useless, I know. And yes, osgText is horrid if you CARE about font quality, but we appear to be the minority. This was actually a bit rude and inadvertently harsh for me to say. What I should have said is: osgText is great if you want 3D text or blazingly-fast text. :) osgPango is good if you're willing to sacrifice a _bit_ of speed (it is slower since I'm not using a custom render function, just special setups of osg::Geometry) for font quality instead, particularly 2D pixel-aligned quality. Date: Tue, 27 Jan 2009 11:17:11 -0500 From: Jeremy Moles jer...@emperorlinux.com Subject: Re: [osg-users] Anti-Grain and OpenSceneGraph To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: 1233073031.3353.40.ca...@dhcp196.emperorlinux.com Content-Type: text/plain; charset=UTF-8 On Tue, 2009-01-27 at 11:06 -0500, Kurt Sierens wrote: Has anyone used the Anti-Grain library in OpenSceneGraph? I would like to get a better looking text display than the osgText node kit does. If you're using Linux, you need to help me with osgPango. :) I have this same goal, and you can find more info (and screenshots) here: http://osgpango.googlecode.com Technically, Pango works on Windows (the Clutter guys use it and it's included in Gimp for Windows), but I've never done it personally so I can't comment. I'm a text display whore myself, so I will settle for absolutely nothing less than near-pixel-perfect display in my own projects. :) Some folks just don't care, but bad font quality is a deal-breaker for me. http://www.antigrain.com/index.html Thanks, Kurt __ Windows Live? Hotmail??more than just e-mail. See how it works. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ Windows Live™: E-mail. Chat. Share. Get more ways to connect. See how it works. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Anti-Grain and OpenSceneGraph
On Wed, 2009-01-28 at 13:58 -0500, Glenn Waldron wrote: Jeremy, Does osgPango support complex scripting for Arabic, etc.? The question really is, does Pango support complex scripting and the answer is yes. :) osgPango is just a Texture caching layer for speed and flexibility in OpenGL. If you can give me some text to throw at the osgpangoviewer app, I'd be happy to run it and show a screenshot. (Although, osgPango does add things on top of Pango such as custom font rendering and effects; it also loses some features though, such as the nice Pango markup language.) Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 On Wed, Jan 28, 2009 at 8:55 AM, John Vidar Larring larr...@weatherone.tv wrote: Hi Jeremy, Kurt, and David, I care too;) In our application we render text as polygon meshes and outlines using FTGL (http://homepages.paradise.net.nz/henryj/code/). The problem with this approach is that FTGL is a pure rendering library and does not have any support for complex scripts (i.e. arabic, hebrew, etc,). However, everything is possible with an ugly hack or two;) John David Spilling wrote: Jeremy, Kurt, I care too! I admit, I've been lurking on the font quality issues because in our apps I have very tight control of the text size and positioning, so can tweak the placement/resolution to get the right look. However developments in this area wld be extremely valuable to me in the long term. Typically though, I have no resource to help develop is, so I will have to remain a lurker... David -- This message has been scanned for viruses and dangerous content by *MailScanner* http://www.mailscanner.info/, and is believed to be clean. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Anti-Grain and OpenSceneGraph (osgWidget Awesomeness)
/humility off Just wanted to share some screenshots with you guys: http://cubicool.plopbyte.net/arabic.png http://cubicool.plopbyte.net/markup.png http://cubicool.plopbyte.net/markup-wireframe.png The arabic.png screenshot is from a request earlier. The markup PNG's demonstrate a feature I just added moments ago that allow you change font weight, style, and family __MIDWAY__ through a layout! Notice how everything is still styled properly and looks crisp, even though we're using different glyph texture caches--bold, italic, and different fonts at different sizes. Sure, we have to change state every time you change font decor, but there's no other choice. All that remains now is support for underline, strike-through, and font color changes (a bit harder to optimize since I push a stack of TexEnvCombine() objects around) and we'll seriously be rocking. Well, and I gotta' figure out why the quality sucks on Windows, but I'm very close to knocking that out! (osgPango absolutely works on Windows, I got it up and running last night. However, Pango can use either Freetype or ClearType to render, and by default it uses ClearType and looks pretty crappy. I just found out how to make Pango use the Freetype backend instead, so I'm anxious to get home and try that out instead, since it's Freetype on Linux that make all those screenshots look so good. :)) I'm very happy right now; I seriously have the skillz. :) /humility on ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
On Mon, 2009-02-02 at 15:01 +, Robert Osfield wrote: Hi All, I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. In prep for the branch I've now updated the version and so numbers so we now have: OpenThreads-2.4.0, SO version 11 OpenSceneGraph-2.8.0, SO version 55 I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. I'm still getting a good deal of warnings (the same from my previous submission); in particular, the one from InteractiveImageHandler in ViewerEventHandlers. On my own system I'm having to fix that every time so that I can use warnings in my code... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
On Mon, 2009-02-02 at 17:20 +0100, Sukender wrote: Hi Jeremy, hi Robert, Robert: Dashboard updated. Jeremy: What kind of machine do you have??? It seems to take ages to compile on my computer (Core2Duo 2.5Ghz)! Or maybe you've compiled just before and there was few to recompile... I have two machines: a laptop (Dell M90 with Core2Duo 1.6Ghz) and a desktop (QuadCore 2.6Ghz). It takes about 20 minutes to build from scratch on my laptop (no including the introspection stuff) and about 5 minutes on my desktop. The laptop runs Fedora 10 and the desktop Vista 64. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 16:56:06 +0100, Jeremy Moles jer...@emperorlinux.com a écrit: On Mon, 2009-02-02 at 15:01 +, Robert Osfield wrote: Hi All, I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. In prep for the branch I've now updated the version and so numbers so we now have: OpenThreads-2.4.0, SO version 11 OpenSceneGraph-2.8.0, SO version 55 I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. I'm still getting a good deal of warnings (the same from my previous submission); in particular, the one from InteractiveImageHandler in ViewerEventHandlers. On my own system I'm having to fix that every time so that I can use warnings in my code... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
On Mon, 2009-02-02 at 17:44 +0100, Sukender wrote: Hi J-S, Hem... I *do* use osgGA wrapper... And yes, I saw they cost much in compile time. :) Yeah, I don't compile the introspection stuff because it makes it take about 40 minutes here, too. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 17:36:49 +0100, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit: Hi Sukender, Alright... Strange thing it took 40 minutes on my machine (which is faster than your laptop, and I had a few *.cpp already compiled). Or maybe you disable compiling wrappers, examples, applications, plugins or such (I do compile them all)? If you don't use the wrappers, disable those. That will likely cut your compile time in half if not more. The wrappers really take a long time to compile. J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
On Mon, 2009-02-02 at 16:23 +, Robert Osfield wrote: Hi Jeremy, Could you please capture the warnings you are getting now. They are almost certainly be the same set as the original warnings you sent as I have fixed hundreds and hundreds and hundreds of warnings, having spent well over a week of my life dedicated to just aggressive warnings level. Please also could specify the compiler options as well - are they different from the standard options used by the OSG? (I only see warnings with 3rd party libs that we can do no thing about on my builds). The only MAJOR one I'm getting anymore is this: In copy constructor ‘osgViewer::InteractiveImageHandler::InteractiveImageHandler(const osgViewer::InteractiveImageHandler, const osg::CopyOp)’: /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class ‘class osg::Object’ should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class ‘class osgGA::GUIEventHandler’ should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class ‘struct osg::Drawable::CullCallback’ should be explicitly initialized in the copy constructor I'm using GCC 4.3 building both my software (osgPango/osgCairo/osgWidget) and OSG itself using: -W -Wall -Wno-unused Speaking of Cairo, what did you ever decide to do about that? :) Robert. On Mon, Feb 2, 2009 at 3:56 PM, Jeremy Moles jer...@emperorlinux.com wrote: On Mon, 2009-02-02 at 15:01 +, Robert Osfield wrote: Hi All, I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. In prep for the branch I've now updated the version and so numbers so we now have: OpenThreads-2.4.0, SO version 11 OpenSceneGraph-2.8.0, SO version 55 I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. I'm still getting a good deal of warnings (the same from my previous submission); in particular, the one from InteractiveImageHandler in ViewerEventHandlers. On my own system I'm having to fix that every time so that I can use warnings in my code... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
On Mon, 2009-02-02 at 17:32 +, Robert Osfield wrote: HI Jeremy, On Mon, Feb 2, 2009 at 5:19 PM, Jeremy Moles jer...@emperorlinux.com wrote: The only MAJOR one I'm getting anymore is this: In copy constructor 'osgViewer::InteractiveImageHandler::InteractiveImageHandler(const osgViewer::InteractiveImageHandler, const osg::CopyOp)': /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'class osg::Object' should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'class osgGA::GUIEventHandler' should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'struct osg::Drawable::CullCallback' should be explicitly initialized in the copy constructor I've just checked in a fix for this. Could you do an svn update and let me know what warnings remain. I'm using GCC 4.3 building both my software (osgPango/osgCairo/osgWidget) and OSG itself using: -W -Wall -Wno-unused Speaking of Cairo, what did you ever decide to do about that? :) For Cairo I've kept the implementations local in the svg and gecko plugins. Rather than go for an CarioImage subclass class, I opted to have a custom user data object that implements the Cario integration. This allows one to add and then remove the Cario support to any image - it needn't be one subclassed from a Cario base class. For 2.8 I've not rolled this Cario helper class out into osgWidget as it was a another little feature that could cause complication and necessitate wider platform testing/debugging. Once 2.8 is out we can look at the issue of exposing an Cario helper class out into osgWidget or other NodeKit. I still think it's probably be best to keep such a class entirely in the header. I agree entirely, and it would be nice to strike osgCairo off my list of software dependencies (especially for osgPango, which I'm making incredible progress on and which now works pleasantly well in Windows). Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
On Mon, 2009-02-02 at 17:32 +, Robert Osfield wrote: HI Jeremy, On Mon, Feb 2, 2009 at 5:19 PM, Jeremy Moles jer...@emperorlinux.com wrote: The only MAJOR one I'm getting anymore is this: In copy constructor 'osgViewer::InteractiveImageHandler::InteractiveImageHandler(const osgViewer::InteractiveImageHandler, const osg::CopyOp)': /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'class osg::Object' should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'class osgGA::GUIEventHandler' should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'struct osg::Drawable::CullCallback' should be explicitly initialized in the copy constructor I've just checked in a fix for this. Could you do an svn update and let me know what warnings remain. The warning remains with the latest revision; osg::Object must also be initialized for this warning to go away. Why this is the case, I do not know. I'm using GCC 4.3 building both my software (osgPango/osgCairo/osgWidget) and OSG itself using: -W -Wall -Wno-unused Speaking of Cairo, what did you ever decide to do about that? :) For Cairo I've kept the implementations local in the svg and gecko plugins. Rather than go for an CarioImage subclass class, I opted to have a custom user data object that implements the Cario integration. This allows one to add and then remove the Cario support to any image - it needn't be one subclassed from a Cario base class. For 2.8 I've not rolled this Cario helper class out into osgWidget as it was a another little feature that could cause complication and necessitate wider platform testing/debugging. Once 2.8 is out we can look at the issue of exposing an Cario helper class out into osgWidget or other NodeKit. I still think it's probably be best to keep such a class entirely in the header. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Blender osgAnimation Issue
On Mon, 2009-02-02 at 22:46 -0800, Ryan Morris wrote: Cedric, Thanks for taking the time to look into this. I did have a revelation a few days ago that lead me to the same conclusion. Basically I had to go back and assign vertices to the named vgroups. not a big deal once I figured it out I was just going crazy thinking I was doing something completely wrong. I figured the exporter should recognize this but it works perfectly if I do the following: -select a vgroup -select the vertices I want in the group -click the assign button I had no idea this WASN'T the way to do it--I'm surprised Blender supports another method. that seemed to fix my issues. Again thanks Cedric for all your help and hard work! -Russ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
