Re: [osg-users] OpenSceneGraph-2.8.0-rc6 tagged, please test
Martin Spott wrote:
> I might offer AIX-5.1 with GCC-4.0.0 - which has, in the past, proven
> to be a quite 'tricky' platform I'm uncertain of you really want
> me to try it ;-)
Ok, unless I'm getting contradictory test results tomorrow, this looks like
a working procedure to build OSG 2.8 on AIX >= 5 with GCC.
1.) Point CMake to CURL- and probably other libraries like:
-D CURL_LIBRARY=/opt/freeware/lib/libcurl.a \
-D CURL_INCLUDE_DIR=/opt/freeware/include/curl
2.) Apparently the test for 'libm' fails on my AIX machine (I'm unable to
tell why), so call CMake with:
-D MATH_LIBRARY=/lib/libm.a
3.) I suspect there's an old workaround for AIX releases _before_ AIX 5.
Presumably the previous releases had their OpenGL headers stored in
/usr/include/OpenGL/. Therefore I had to modify a little compile time
switch:
diff -urNb include/osg.release/GLU include/osg/GLU
--- include/osg.release/GLU Wed Oct 3 22:21:01 2007
+++ include/osg/GLU Sun Feb 22 21:59:07 2009
@@ -16,7 +16,8 @@
#include
-#if defined(__APPLE__) || defined (_AIX)
+#if defined(__APPLE__) || \
+(defined (_AIX) && !defined (_AIX51))
#include
#else
#include
4.) Finally, almost all of the floating point types seem to be undefined on
AIX, at least with GCC - I decided to re-use some switches which are alredy
in place for the use on other commercial Unix systems:
diff -urNb include/osg.release/Math include/osg/Math
--- include/osg.release/MathSun Nov 23 12:35:43 2008
+++ include/osg/MathSun Feb 22 22:24:46 2009
@@ -44,7 +44,9 @@
#include
#endif
-#if defined (sun) || defined (__APPLE__)
+#if defined (sun) || \
+defined (__APPLE__) || \
+(defined (_AIX) && defined (__GNUC__))
#include
@@ -93,7 +95,8 @@
#if defined (sun) || \
defined (__hpux) || \
-defined (APPLE_PRE_10_2)
+defined (APPLE_PRE_10_2) || \
+(defined (_AIX) && defined (__GNUC__))
#ifndef floorf
inline float floorf(float value) { return
static_cast(floor(value)); }
Even though my server has 8 CPU's, they only run at 200 MHz each, so I don't
expect the build to be ready before tomorrow :-)
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fixed function pipeline -> GLSL shaders
Hi Paul, On Sun, Feb 22, 2009 at 8:38 PM, Paul Martz wrote: > Hi Robert -- You are totally right, and I came to the same conclusion as you > after sleeping on it. There could be an OpenGL3x-based core library, just a > thin wrapper around OpenGL3x with some base scene graph functionality, which > sits under an OSG2x compatibility library, and use of the latter is > completely optional, much as NodeKits are optional today. I'm not sure about the totally right... once we've actually got code working and it works well could we say they we might be on the right track. That's part of the fun though... none of know how exactly things are going to pan out over the next five years, some stuff will work well, other approaches won't. > I'd imagine that the OSG2x compatibility library might define some > full-function shaders, and existing StateAttributes modified to create > Uniforms consumed by those shaders. Anyone writing their own shaders would > have the option of using OSG2x uniforms, their own uniforms, or some > combination thereof. I currently think of current OpenGL 2.x as modes enabling/disabling sets of shaders, and StateAttributes as setting of one or more uniforms associated with these shaders. The OSG's doesn't currently manage shaders like this though, osg::Uniforms and osg::Program sit completely orthogonal to the fixed function pipeline. One could hide GL3 shaders/unfirms within internally mapping between modes/StateAtttributes, and this might even be a first step - it's something that is relevant to GL2 as much as GL3 so one could even experiment with this in GL2. I think the next step would be to evolve the OSG's management of Modes and StateAttributes such that the mapping to enable/disabling shaders and setting of groups of uniforms is much more seamless. One might even get to the point where osg::Program/osg::Shader, osg::Uniform, osg::StateAttribute and osg::StateSet need to be revamped to fit with this more transparent mapping. Is such an API leap an OSG 3.x step though? > In the "break with compatibility" category, I thought about eliminating the > Geometry and Drawable objects. Consider the following: Today, you attach a > texture object to some StateSet, and the current texture is determined by > OSG's rules of state inheritance. Now consider doing the same thing with > buffer objects containing vertex attributes: If you could attach them to a > StateSet and let them inherit like texture objects or any other state, > Geodes would only need to contain PrimitiveSets, and the PrimitiveSets would > simply sources from the current buffer object. Wow. I have in passing thought about the possibility of StateSets being able to define vertex attributes, but hadn't thought about it in the context of GL3 dev, and haven't thought about it for a long time, so long I had forgotten! One problem with decoupling the vertex definitions for PrimitiveSets would be that you wouldn't know how to compute the bounding volume of the leaves, one would only be able to compute the bounding box when the vertex data is attached. One could inherit the vertex data down to the leaves, but if you have two parental paths then the leaves could inherit two or more sets of vertex data. There is also the question about the coordinate system that vertices would be in, for instance what do you do is there is a transform below where the vertices are attached, but about the primitive leaves? Finally there is the issue of ensuring that the primitive sets have all the vertex data they require, a looser coupling would be that scene graph consistency would have to be more carefully managed. Inheriting other vertex attributes is somewhat easier though as there isn't the same bounding volume issue, but still does have a few potential pitfalls so if we do introduce this flexibility we'd need to be mindful of these pitfalls. Robert. > Just stray thoughts, but these are some exciting possibilities, for certain. > > Paul Martz > Skew Matrix Software LLC > http://www.skew-matrix.com > +1 303 859 9466 > > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert > Osfield > Sent: Sunday, February 22, 2009 3:57 AM > To: OpenSceneGraph Users > Subject: Re: [osg-users] Fixed function pipeline -> GLSL shaders > > Hi Paul, > > I agree broadly on these two approaches, and rather than one or other them > we might be best served by doing both. Option 1 is the easier for an OSG > 2.x series to accommodate and could serve as testing ground for Option 2. > Such an approach possible allow us to make it easier to migrate users from > one approach to the other. > > My current thought is see if we can make tweaks to OSG 2.x that change the > API in small ways that enable exiting users to port easily from one version > to the next and close the gap on the leap to a more API agnostitc scene > graph, rather than an OpenGL 2.x centric sce
Re: [osg-users] Defining "NodeKit"
On Sun, Feb 22, 2009 at 8:11 PM, Paul Martz wrote: >> osgAnimation, osgWidget and osgVolume all have plugins that >> support reading and writing of extended .osg files. These are all >> full NodeKits, as they all directly extend the scene graph nodes, >> drawable + state. > > Thanks for the correction. I didn't see the build target for the OSG support > for those, but I do now. Eyesight continues to fail... :-( We need to bypass your optics and wire a text + graphics renderer directly to your brain. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fixed function pipeline -> GLSL shaders
Hi Robert -- You are totally right, and I came to the same conclusion as you after sleeping on it. There could be an OpenGL3x-based core library, just a thin wrapper around OpenGL3x with some base scene graph functionality, which sits under an OSG2x compatibility library, and use of the latter is completely optional, much as NodeKits are optional today. I'd imagine that the OSG2x compatibility library might define some full-function shaders, and existing StateAttributes modified to create Uniforms consumed by those shaders. Anyone writing their own shaders would have the option of using OSG2x uniforms, their own uniforms, or some combination thereof. In the "break with compatibility" category, I thought about eliminating the Geometry and Drawable objects. Consider the following: Today, you attach a texture object to some StateSet, and the current texture is determined by OSG's rules of state inheritance. Now consider doing the same thing with buffer objects containing vertex attributes: If you could attach them to a StateSet and let them inherit like texture objects or any other state, Geodes would only need to contain PrimitiveSets, and the PrimitiveSets would simply sources from the current buffer object. Just stray thoughts, but these are some exciting possibilities, for certain. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Sunday, February 22, 2009 3:57 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Fixed function pipeline -> GLSL shaders Hi Paul, I agree broadly on these two approaches, and rather than one or other them we might be best served by doing both. Option 1 is the easier for an OSG 2.x series to accommodate and could serve as testing ground for Option 2. Such an approach possible allow us to make it easier to migrate users from one approach to the other. My current thought is see if we can make tweaks to OSG 2.x that change the API in small ways that enable exiting users to port easily from one version to the next and close the gap on the leap to a more API agnostitc scene graph, rather than an OpenGL 2.x centric scene graph. One step might be to rejig the granularity of StateAttribute's so that they have one mode per attribute for all attributes, rather the current situation of have on attribute wrap up mulitple modes (i.e. osg::TexGen / osg::Material). Another step would be to move all GL dependencies out for the headers, and keep it all in the implementation. Another step would be creating mapping between attributes and their shader + uniform counter parts, and provide a mechanism for composing this together in the rendering backend. Some of these steps needn't break existing API, and could be done in parallel to existing development. For instance adding GL3 context support into osgViewer should be possible now that the drivers are out, and this would give the ability to start experimenting. Robert. On Sat, Feb 21, 2009 at 4:06 PM, Paul Martz wrote: > I guess there's really two different philosophical directions that OSG > can take in the OpenGL3.x timeframe. Maybe there's more than two, but > the two I can think of are as follows: > > 1) Backwards compatibility. Continue to support the existing OSG API > to enable apps to transparently port to OpenGL 3.x. OSG emulates the > fixed function pipe by creating Uniforms for state attributes and > modes and supplying default shaders that use the Uniforms to reproduce > the old OpenGL 2.x functionality. > > Note that option 1 doesn't preclude users from accessing the 3.x > interface through their own uniforms and shaders. However, it retains the "conflict" > that OpenGL 3.x resolves, namely, an API that appears to guarantee > certain functionality, which breaks when the wrong shader is loaded. > > 2) Break with compatibility. Remove from the OSG API all state > attributes or other OSG functionality that relies on the fixed > function pipe. OSG becomes a spatial organizer and mechanism for > loading user-defined uniforms and textures into user-defined shaders. > > Seems like both have pros and cons, which I don't have the time to > enumerate this morning. Personally, I've been leaning towards option > 2, which seems cleaner and more in spirit with OpenGL 3.x; the major > downside, of course, is the immense porting effort inflicted on app > developers who decide they can't stay on OSG/OpenGL 2.x. To which I > would say a) that's their choice, as OSG/OpenGL 2.x will be available > for years to come, and b) API ports have been done successfully in the > past: Starbase PHIGS, PEX, etc., no one misses them. > > Paul Martz > Skew Matrix Software LLC > http://www.skew-matrix.com > +1 303 859 9466 > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://list
Re: [osg-users] Non emissive ParticleSystem and lighting
Sukender, Look for premultiplied alpha. This allows for mixing additive and alpha blending in a single texture. See http://home.comcast.net/~tom_forsyth/blog.wiki.html#[[Premultiplied%20alpha]] -- Roland -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7171#7171 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Defining "NodeKit"
> osgAnimation, osgWidget and osgVolume all have plugins that > support reading and writing of extended .osg files. These are all > full NodeKits, as they all directly extend the scene graph nodes, > drawable + state. Thanks for the correction. I didn't see the build target for the OSG support for those, but I do now. Eyesight continues to fail... :-( -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] floor looks dark
Daniel, viewing your model in osgviewer by default lights it with a headlight, which will result in all surfaces that are parallel to the viewing direction to show as dark. Use lights in the scene to better light the model. The problem with the floor not always showing is due to the fact that both the windows and the floor are semi-transparent. They are both in the transparent bin and will be sorted rather coursely from back to front. This means that sometimes a window is drawn before a floor element is drawn and this will prevent the floor element to correctly show through the window. For your specific model you could set the floor to a smaller bin number than the windows. This way the floor will always be drawn before the windows. Or simply make the floor opaque. -- Roland -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7169#7169 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] floor looks dark
Hi, thanks for the answer. I tried to disable backface culling, and the only visible effect that I got was that rendering became some 2-3 times faster (which is good by itself). However, the "floor effect" remains. It looks like it is shaded somehow strangely, using clear color. On Wed, Feb 18, 2009 at 10:39 PM, Jason Daly wrote: > Daniel Drubin wrote: >>> >>> thanks for response, but it doesn't help :-( >>> Another thing that I notice, the floor not only gets darkened, it also >>> receives coloring from "clear color", if that makes sense. >>> Does anybody have an idea? >>> > > If that's true, it sounds like you're not seeing the floor at all. That is, > you're seeing the back of the floor, which is getting culled by backface > culling. A quick way to check for this is to disable backface culling on > your scene (look at osg/CullFace). > > --"J" > > ___ > 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] Non emissive ParticleSystem and lighting
Hi Sukender, I would actually like to see osgParticle completely rewritten using shaders as well as a fallback with non shader fallback. I think loosing a bit of it's current flexibility to be able to use shaders would making for far faster particle and scalable systems. Animated textures would also be an interesting addition as well. Throw into the mix better lighting controls too. Robert. On Sun, Feb 22, 2009 at 4:29 PM, Sukender wrote: > Hi Robert, > > Hmmm... Could be of course! But as it is a non-critical feature for me, I > must admit I've put the task down my TodoList, with a low priority ;) > Nevertheless, it would be nice to have particles that can interact with > diffuse and/or ambient, so that the development effort of users would be > reduced to almost nothing. > > Sukender > PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ > > > Le Sun, 22 Feb 2009 11:41:45 +0100, Robert Osfield > a écrit: > >> On Fri, Feb 20, 2009 at 8:37 PM, Sukender wrote: >>> Hi Christophe, >>> >>> I also use fire/smoke effects, and actually all are emissive (= bright at >>> night). If you get a solution, I'm interested! ;) >> >> Can't you change the particle colour to be appropriate for different >> times of day? >> >> 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
Re: [osg-users] Non emissive ParticleSystem and lighting
Hi Robert, Hmmm... Could be of course! But as it is a non-critical feature for me, I must admit I've put the task down my TodoList, with a low priority ;) Nevertheless, it would be nice to have particles that can interact with diffuse and/or ambient, so that the development effort of users would be reduced to almost nothing. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Sun, 22 Feb 2009 11:41:45 +0100, Robert Osfield a écrit: > On Fri, Feb 20, 2009 at 8:37 PM, Sukender wrote: >> Hi Christophe, >> >> I also use fire/smoke effects, and actually all are emissive (= bright at >> night). If you get a solution, I'm interested! ;) > > Can't you change the particle colour to be appropriate for different > times of day? > > 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] LOD terrain generation
Hi Peter, On Sun, Feb 22, 2009 at 3:29 PM, Peter wrote: > Implementation of program for generation of terrain isn't part of the > project, but it looks like I don't have any other choice. Terrain generation isn't part of the project, but a specific type of terrain database is required... and one that isn't even particular efficient... Personally I'd double check with the supervisor that off the shelf generated terrain in a quad tree form isn't appropriate. If you really have to have a single tile with multiple LOD levels then go create a single tile a full res and use the osgUtil::Simplifer to cut down the number of vertices/polygons to create the multiple LOD levels. You'll need to create the LOD's and clone the geometry at each simplification stage but it shouldn't be too much work - you could probably do it in a hundred lines of code. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LOD terrain generation
Hi Robert, Implementation of program for generation of terrain isn't part of the project, but it looks like I don't have any other choice. Peter Robert Osfield wrote: > Hi Peter, > > On Sun, Feb 22, 2009 at 12:43 PM, Peter <> wrote: > > > I understand that the osgdem (quad tree) have a lot of advantages, but it > > is for my school project and I really need to implement algorithm, which > > uses database that I described. > > > > Shouldn't you be implementing the work yourself if you're doing a > school project > > Robert. > ___ > osg-users mailing list > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > -- > Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7162#7162 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera position
тогда у тебя два варианта -
1) послушать Роберта (Use getCamera()->getViewMartix*()...)
2) отказаться от этого манипулятора и реализовать свой, посредством контроля
мыши например (это не сложно .. я так всегда делаю.. как управл. камерой
я показал)
удачи. И тут на английском нужно..)
2009/2/22 Alexey Yurov
>
> Максим Гаммер wrote:
> > //передвигаем камеру в соответствии с координатами пользователя и
> направлением его взгляда
> > //следующие объявления отвечают за создание пользовательской камеры
> > osg::Matrixd myCameraMatrix;
> > osg::Matrixd cameraRotation;
> > osg::Matrixd cameraTrans;
> >
> > float xtrans = BodyX;
> > float ztrans = BodyY;
> > float ytrans = BodyZ;
> > float xrotate = 360.0f - HeadX;
> > float yrotate = HeadY;//UserInput->getYrotate();
> > float zrotate = HeadZ;
> >
> > cameraRotation.makeRotate(
> > osg::DegreesToRadians(zrotate), osg::Vec3(0,1,0), // roll
> > osg::DegreesToRadians(yrotate), osg::Vec3(1,0,0) , // pitch
> > osg::DegreesToRadians(xrotate), osg::Vec3(0,0,1) ); // heading
> >
> > cameraTrans.makeTranslate( xtrans,ztrans,ytrans );
> > myCameraMatrix = cameraRotation * cameraTrans;
> >
> > osg::Matrixd i = myCameraMatrix.inverse(myCameraMatrix);
> >
> UserOutput->getViewer()->getCamera()->setViewMatrix((osg::Matrixd(i.ptr()))*
> osg::Matrixd::rotate( -3.14f / 2.0, 1, 0, 0 ));
> >
> >
> > MAX,
> >
> > 2009/2/21 Alexey Yurov <>
> >
> > > Hi all, it's my first expirience in openscenegraph (v2.6), and i need
> ur help plz. In my application i need to get camera position every frame, i
> try do this:
> > >
> > > Code:
> > >
> > > while(!viewer.done())
> > > {
> > > viewer.getCamera()->getViewMatrixAsLookAt(eye, center, up);
> > > //eye hold camera pos???
> > > viewer.frame();
> > > }
> > >
> > >
> > >
> > > or there is another way to get it?
> > >
> > > --
> > > Read this topic online here:
> > > http://forum.openscenegraph.org/viewtopic.php?p=7145#7145 (
> http://forum.openscenegraph.org/viewtopic.php?p=7145#7145)
> > >
> > >
> > >
> > >
> > >
> > > ___
> > > osg-users mailing list
> > > ()
> > >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org(
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org)
> > >
> >
> >
> >
> > --
> > Гаммер Максим Дмитриевич
> > Начальник отдела ИТ НИИ ЭОР
> >
> > --
> > Post generated by Mail2Forum
>
> Я использую TrackballManipulator и мне из viwera' нужно каждый кадр
> извлекать позицию камеры
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=7157#7157
>
>
>
>
>
> ___
> 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] LOD terrain generation
Hi Peter, On Sun, Feb 22, 2009 at 12:43 PM, Peter wrote: > I understand that the osgdem (quad tree) have a lot of advantages, but it is > for my school project and I really need to implement algorithm, which uses > database that I described. Shouldn't you be implementing the work yourself if you're doing a school project Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LOD terrain generation
Hi Robert, I understand that the osgdem (quad tree) have a lot of advantages, but it is for my school project and I really need to implement algorithm, which uses database that I described. Peter Robert Osfield wrote: > Hi Peter, > > VirtualPlanetBuilder/osgdem builds a quad tree, which is far more > efficient and scalable for managing LOD's than just having a single > tile with multiple LODs. I wouldn't recommend using multiple LOD > levels on a single tile for terrain database, using such an approach > is far better suited to objects in the scene rather than terrain. > > Robert. > > On Fri, Feb 20, 2009 at 10:08 PM, Peter <> wrote: > > > Hi, > > > > I would like to make LOD or PagedLOD database, but it seems that osgdem > > doesn't make type of database which I need. If I understand the osgdem > > right, it has different size for each level of detail tile. But I need same > > size for all tiles. Osgdem database is proposed like quad tree (I think) > > but I need a flat layout. Something like: > > > > . . . . pagedLOD/LOD_node > > level1. . level2. . level3. . levelN > > > > Does exist any program for generation this type of database? > > Thanks and excuse my bad English. > > > > Peter > > > > -- > > Read this topic online here: > > http://forum.openscenegraph.org/viewtopic.php?p=7142#7142 > > > > > > > > > > > > ___ > > osg-users mailing list > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > ___ > osg-users mailing list > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > -- > Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7158#7158 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera position
Максим Гаммер wrote:
> //передвигаем камеру в соответствии с координатами пользователя и
> направлением его взгляда
> //следующие объявления отвечают за создание пользовательской камеры
> osg::Matrixd myCameraMatrix;
> osg::Matrixd cameraRotation;
> osg::Matrixd cameraTrans;
>
> float xtrans = BodyX;
> float ztrans = BodyY;
> float ytrans = BodyZ;
> float xrotate = 360.0f - HeadX;
> float yrotate = HeadY;//UserInput->getYrotate();
> float zrotate = HeadZ;
>
> cameraRotation.makeRotate(
> osg::DegreesToRadians(zrotate), osg::Vec3(0,1,0), // roll
> osg::DegreesToRadians(yrotate), osg::Vec3(1,0,0) , // pitch
> osg::DegreesToRadians(xrotate), osg::Vec3(0,0,1) ); // heading
>
> cameraTrans.makeTranslate( xtrans,ztrans,ytrans );
> myCameraMatrix = cameraRotation * cameraTrans;
>
> osg::Matrixd i = myCameraMatrix.inverse(myCameraMatrix);
> UserOutput->getViewer()->getCamera()->setViewMatrix((osg::Matrixd(i.ptr()))*
> osg::Matrixd::rotate( -3.14f / 2.0, 1, 0, 0 ));
>
>
> MAX,
>
> 2009/2/21 Alexey Yurov <>
>
> > Hi all, it's my first expirience in openscenegraph (v2.6), and i need ur
> > help plz. In my application i need to get camera position every frame, i
> > try do this:
> >
> > Code:
> >
> > while(!viewer.done())
> > {
> > viewer.getCamera()->getViewMatrixAsLookAt(eye, center, up);
> > //eye hold camera pos???
> > viewer.frame();
> > }
> >
> >
> >
> > or there is another way to get it?
> >
> > --
> > Read this topic online here:
> > http://forum.openscenegraph.org/viewtopic.php?p=7145#7145
> > (http://forum.openscenegraph.org/viewtopic.php?p=7145#7145)
> >
> >
> >
> >
> >
> > ___
> > osg-users mailing list
> > ()
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> > (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org)
> >
>
>
>
> --
> Гаммер Максим Дмитриевич
> Начальник отдела ИТ НИИ ЭОР
>
> --
> Post generated by Mail2Forum
Я использую TrackballManipulator и мне из viwera' нужно каждый кадр извлекать
позицию камеры
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=7157#7157
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera position
Hi Alexey,
Use getCamera()->getViewMartix*() methods is the appropriate thing to
do. You might want to split the viewer.frame() into it's constituent
parts to make sure that you can the view matrix that is appropriate
for the frame you are working on - the viewer.updateTraversal() method
updates the view matrix on each frame. Have a look at the source to
viewer.frame() to see what it's made from.
Robert
On Sat, Feb 21, 2009 at 1:33 PM, Alexey Yurov wrote:
> Hi all, it's my first expirience in openscenegraph (v2.6), and i need ur help
> plz. In my application i need to get camera position every frame, i try do
> this:
>
> Code:
>
> while(!viewer.done())
> {
> viewer.getCamera()->getViewMatrixAsLookAt(eye, center, up);
> //eye hold camera pos???
> viewer.frame();
> }
>
>
>
> or there is another way to get it?
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=7145#7145
>
>
>
>
>
> ___
> 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] Defining "NodeKit"
Hi Paul, osgAnimation, osgWidget and osgVolume all have plugins that support reading and writing of extended .osg files. These are all full NodeKits, as they all directly extend the scene graph nodes, drawable + state. osgGA isn't a NodeKit, it's just a utility library like osgUtl or osgDB. In a future rev of the OSG I'm wanting to refactor/update osgGA classes and merge into osgViewer/osgWidget core OSG. Robert. On Sat, Feb 21, 2009 at 11:02 PM, Paul Martz wrote: > Hi Robert and all -- As I proceed with updating the Quick Start Guide, I > encountered the section describing OSG's NodeKits. My first inclination was > to update this with a short description of osgAnimation, osgVolume, and > osgWidget. > > However, only osgAnimation appears to have a dot osg plugin. osgVolume and > osgWidget apparently do not define any classes that are supported by dot > osg. Looking closer, I see that there is no dot osg plugin for > osgManipulator or osgGA either. > > Do we need a new category for OSG-based libraries that aren't NodeKits? Or > do I need to change my definition of NodeKit to be more inclusive? Thanks > for any suggestions. > > Paul Martz > Skew Matrix Software LLC > 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
Re: [osg-users] OSG Books (was: RE: Number of contributors)
Hi Paul, On Sat, Feb 21, 2009 at 9:55 PM, Paul Martz wrote: > Thanks, Robert. I really just need the URL for the old Professional Support > page, which used to be here: > > http://www.openscenegraph.org/osgwiki/pmwiki.php/Support/Support > > I can't find the new location, not by searching the wiki for the obvious > "professional support", at least. We there is more than one company providing professional support today so might I suggest a list of websites such as openscenegraph.com, skew-matrix.com etc. There shouldn't be any need to deep links that the above. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fixed function pipeline -> GLSL shaders
Hi Paul, I agree broadly on these two approaches, and rather than one or other them we might be best served by doing both. Option 1 is the easier for an OSG 2.x series to accommodate and could serve as testing ground for Option 2. Such an approach possible allow us to make it easier to migrate users from one approach to the other. My current thought is see if we can make tweaks to OSG 2.x that change the API in small ways that enable exiting users to port easily from one version to the next and close the gap on the leap to a more API agnostitc scene graph, rather than an OpenGL 2.x centric scene graph. One step might be to rejig the granularity of StateAttribute's so that they have one mode per attribute for all attributes, rather the current situation of have on attribute wrap up mulitple modes (i.e. osg::TexGen / osg::Material). Another step would be to move all GL dependencies out for the headers, and keep it all in the implementation. Another step would be creating mapping between attributes and their shader + uniform counter parts, and provide a mechanism for composing this together in the rendering backend. Some of these steps needn't break existing API, and could be done in parallel to existing development. For instance adding GL3 context support into osgViewer should be possible now that the drivers are out, and this would give the ability to start experimenting. Robert. On Sat, Feb 21, 2009 at 4:06 PM, Paul Martz wrote: > I guess there's really two different philosophical directions that OSG can > take in the OpenGL3.x timeframe. Maybe there's more than two, but the two I > can think of are as follows: > > 1) Backwards compatibility. Continue to support the existing OSG API to > enable apps to transparently port to OpenGL 3.x. OSG emulates the fixed > function pipe by creating Uniforms for state attributes and modes and > supplying default shaders that use the Uniforms to reproduce the old OpenGL > 2.x functionality. > > Note that option 1 doesn't preclude users from accessing the 3.x interface > through their own uniforms and shaders. However, it retains the "conflict" > that OpenGL 3.x resolves, namely, an API that appears to guarantee certain > functionality, which breaks when the wrong shader is loaded. > > 2) Break with compatibility. Remove from the OSG API all state attributes or > other OSG functionality that relies on the fixed function pipe. OSG becomes > a spatial organizer and mechanism for loading user-defined uniforms and > textures into user-defined shaders. > > Seems like both have pros and cons, which I don't have the time to enumerate > this morning. Personally, I've been leaning towards option 2, which seems > cleaner and more in spirit with OpenGL 3.x; the major downside, of course, > is the immense porting effort inflicted on app developers who decide they > can't stay on OSG/OpenGL 2.x. To which I would say a) that's their choice, > as OSG/OpenGL 2.x will be available for years to come, and b) API ports have > been done successfully in the past: Starbase PHIGS, PEX, etc., no one misses > them. > > Paul Martz > Skew Matrix Software LLC > 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
Re: [osg-users] LOD terrain generation
Hi Peter, VirtualPlanetBuilder/osgdem builds a quad tree, which is far more efficient and scalable for managing LOD's than just having a single tile with multiple LODs. I wouldn't recommend using multiple LOD levels on a single tile for terrain database, using such an approach is far better suited to objects in the scene rather than terrain. Robert. On Fri, Feb 20, 2009 at 10:08 PM, Peter wrote: > Hi, > > I would like to make LOD or PagedLOD database, but it seems that osgdem > doesn't make type of database which I need. If I understand the osgdem right, > it has different size for each level of detail tile. But I need same size for > all tiles. Osgdem database is proposed like quad tree (I think) but I need a > flat layout. Something like: > > . . . . pagedLOD/LOD_node > level1. . level2. . level3. . levelN > > Does exist any program for generation this type of database? > Thanks and excuse my bad English. > > Peter > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=7142#7142 > > > > > > ___ > 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] Non emissive ParticleSystem and lighting
On Fri, Feb 20, 2009 at 8:37 PM, Sukender wrote: > Hi Christophe, > > I also use fire/smoke effects, and actually all are emissive (= bright at > night). If you get a solution, I'm interested! ;) Can't you change the particle colour to be appropriate for different times of day? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DrawArrays and bind_per_primitive
HI Steven, On Fri, Feb 20, 2009 at 7:34 PM, Steven Saunderson wrote: > Thanks for this tip; I wasn't aware of the performance penalty. > > Does this also apply to BIND_OVERALL ? I have many single entry arrays for > colour. If these are expensive from a performance viewpoint then I'll > definitely expand them. BIND_OVERALL, BIND_PER_PRIMITIVE_SET and BIND_PER_VERTEX all work on OpenGL fast paths. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera position
//передвигаем камеру в соответствии с координатами пользователя и
направлением его взгляда
//следующие объявления отвечают за создание пользовательской камеры
osg::Matrixd myCameraMatrix;
osg::Matrixd cameraRotation;
osg::Matrixd cameraTrans;
float xtrans = BodyX;
float ztrans = BodyY;
float ytrans = BodyZ;
float xrotate = 360.0f - HeadX;
float yrotate = HeadY;//UserInput->getYrotate();
float zrotate = HeadZ;
cameraRotation.makeRotate(
osg::DegreesToRadians(zrotate), osg::Vec3(0,1,0), // roll
osg::DegreesToRadians(yrotate), osg::Vec3(1,0,0) , // pitch
osg::DegreesToRadians(xrotate), osg::Vec3(0,0,1) ); // heading
cameraTrans.makeTranslate( xtrans,ztrans,ytrans );
myCameraMatrix = cameraRotation * cameraTrans;
osg::Matrixd i = myCameraMatrix.inverse(myCameraMatrix);
UserOutput->getViewer()->getCamera()->setViewMatrix((osg::Matrixd(i.ptr()))*
osg::Matrixd::rotate( -3.14f / 2.0, 1, 0, 0 ));
MAX,
2009/2/21 Alexey Yurov
> Hi all, it's my first expirience in openscenegraph (v2.6), and i need ur
> help plz. In my application i need to get camera position every frame, i try
> do this:
>
> Code:
>
> while(!viewer.done())
> {
> viewer.getCamera()->getViewMatrixAsLookAt(eye, center, up);
> //eye hold camera pos???
> viewer.frame();
> }
>
>
>
> or there is another way to get it?
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=7145#7145
>
>
>
>
>
> ___
> 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
