Re: [osg-users] Multiple lights in a scene
Hi Chris, Hi Jean-Sébastien
I just ending a similar work for a client and i could provide some advice on
the subject.
First, I derived from osg::LightSource to osgLighting::LightSource (that
could contain many light, not only one as osg::LightSource) and add a
cullCallback to do a similar job of
osgUtil::CullVisitor::accept(osg::LightSource).
I create a osgLighting::LightGroup (not a node) which contain light
parameter (ambient, diffuse, position, direction ...)
in uniforms arrays, and be shared by all lights
I derived from osg::Light to osgLighting::Light that contain an
osgLighting::LightGroup to store parameter in it.
Shader is handle by a shader generator so I can't help you on this point.
But I conclude after some test that per pixel lighting is not a choice.
If you want apply shadow per light, you have to combine each light/shadow
pair
in the pixel shader. you can't compute light in vertex shader, then pass
result of each light
in pixel shader, and apply shadow on each light result. if you have 40
lights in you scene.
you have to pass 40 vec3 from vertex shader to pixel shader ouch!!!
according to Real-Time Rendering 3ed,
Shader Model 4 have 16 interpolation registre between Vertex and
Geometry/Pixel Shader and
32 between Geometry and Pixel Shader.
J-S:
About deferred shading, this is my first reflex to not pay the Z complexity
of the scene.
But OpenGL allow only 8 texture target to render in, so 8*4=32 values.
We can use 3 for eye position, 3 for normal. This let's us with 26 value to
pass light direction/position.
That is largely under the need to handle more that 8 lights.
I read an article about Unreal Engine that push the 3 nearest lights in RTT,
and all others lights are combined in one, so only 4 light is pass to RTT,
then computed in deferred shader.
I have to dig this way ...
Still according to Real Time Rendering 3ed, if you don't write the
gl_FragDepth in your shader, recent hardware
discard automatically the pixel computation if pixel in frame buffer is
front of the incoming pixel.
You can use OSG_DEFAULT_BIN_SORT_MODE=SORT_FRONT_TO_BACK to help hardware to
do the job.
I am in negotiation with my client to put osgLighting and osgGLSL (the
shader generator) in OpenSource.
But this will not happen before summer I think. Many people to convince that
OpenSource is the good way for every body.
HTH
David Callu
2011/4/19 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com
Hi Chris,
First of all, I have to commend you on all the work you've put into doing
this. You obviously put a lot of thought and research into your problem, and
explored multiple avenues before posting, which I have to admire!
I've personally never needed more than the 8 light sources the fixed
pipeline gave me, so I've always used the built-in gl_LightSource[i]
structure and osg::LightSource+osg::Light to manage my lights. I have a
mechanism in place that lets me reuse light IDs when lights get turned on or
off (a light turned off frees its light ID, and a light turned on will take
the first available light ID), and this uses IDs 0-7, which has been
sufficient for me. Add to that the fact that OSG's built-in shadow
techniques support casting shadows from only one light, and I've never
really had a need (personally or from client requirements) to go further.
But that's not to say it won't happen.
What I'd say in response to your question is, I think you have a good idea
of what is the best solution to your problem (solution 1), but it requires
some small changes to OSG itself in order to be feasible. So what prevents
you from proposing these changes? Robert hasn't been against making some
methods virtual when needed in the past, and even deeper changes will be
possible when they're justified.
About the CullVisitor, I don't understand what you mean about not
recognizing new classes. First of all, sure, you could add new classes to
its interface, but even if not, you can always, in the
accept(osg::LightSource) method, check with a dynamic_cast if the
lightSource is of your derived class:
virtual void accept(osg::LightSource ls)
{
if (dynamic_castmyOwnLightSource*(ls) != 0)
{
// My light source subclass.
}
else
{
// Plain old osg::LightSource
}
}
But whatever you decide, I think you shouldn't rule out changes to the core
OSG. The fixed pipeline is out, and shaders are in, and if OSG could be made
to support its own osg_LightSource[i] uniforms, with indices limited only by
shader memory (while not ruling out the possibility that the first 8 of
those be mapped to the fixed pipeline light sources if the fixed pipeline is
available) then that would be very nice indeed.
I'll just add one last note, another way to deal with many light sources
would be to do deferred shading, maybe you should look this up. It all
depends on what you're doing, but deferred shading has the advantage that
all complex lighting calculations (per pixel lighting, normal mapping, etc.)
Re: [osg-users] clipping problem with PagedLODs
Hi Jason, The wa that the OSG handles positional state like clip planes is pair the a specific modelview matrix with the positional state, the modelview matrix used in provided when the cull traversal encounters a positional state node like ClipNode, TexGenNode or LightSource, and the pairing is done such that there is only one posible modelview matrix per positional state, on per RenderStage basis. This approach ensures that clip planes, eye linear texgen and light sources all have a single place in space for rendering a whole stage, but it does mean you can't reuse a clip plane, eye linear tex gen, or light within on stage. The only ways to support multiple clip planes or other positional state is to dispense with the positional state nodes completely and have custom state attribute that binds a specific modelview matrix to that state and applies this before applying the state, but straight away after applying the state will need to restore the original modelview matrix. You will also need to geneate the specific modelview matrix somehow, a custom node like ClipNode might be approrpriate. How this all relates to what you have done I can't say, there is no way for me to comment as the code is infront of you not me. Robert. On Mon, Apr 18, 2011 at 11:48 PM, Jason Jerald ja...@dartforms.com wrote: I created two new classes: ClipNodeReused inherited from ClipNode, and ClipPlaneReused from ClipPlane (basically just overriding apply(osg::State)). These classes enable me to reuse the OpenGL clipping planes so that I can do more than the graphics hardware limit of 6-8 clipping planes. This has worked well. However, I recently discovered that some model files do not get clipped correctly. The only thing that I see is different about these files is that they contain PagedLODs. I am not sure of the details of LODs to know if some form of clipping (perhaps as part of some form of culling?) might be happening that is keeping my custom clipping from occurring. Have others been able to clip PagedLODs successfully? Any ideas what might be going wrong here? Thanks! 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
Re: [osg-users] addSlave messup main cameras stateset
HI Suneel,
From reading your post there is no way I can guess what is going on in
your app. There is no reason for the OSG to detach a StateSet from a
master Camera so would presume there is something wrong in your code,
as to what I can't not guess as there is too little information. I
would recommend just stepping through you app and double check all the
code and assumptions you are making.
Robert.
On Tue, Apr 19, 2011 at 6:15 AM, suneel suresh compres...@gmail.com wrote:
hi in order to display a rectangle roi over the 3d scene i use the example
provided in osg hud. however before drawing the roi i press a toggle
selection button which gets the stateset of the main camera as given below
Code:
osg::StateSet *stateSet = osg_viewer-getCamera()-getOrCreateStateSet();
osg::Point *pointState =
(osg::Point*)stateSet-getAttribute(osg::StateAttribute::POINT);
The 2d rectangle is drawn by mouse drag using the handler function. In the
handler function the slave camera is created and added to the viewer as
addSlave.
Code:
case(osgGA::GUIEventAdapter::PUSH):
{
camera_slaveBBox = createBBoxCamera();
viewer-addSlave(camera_slaveBBox, false);
}
As the mouse the dragged the rectangle is drawn and all is good
untill..On pressing the toggle selection button again in the first code
stateSet is now returned NULL :(
Now if i comment
Code:
//commentviewer-addSlave(camera_slaveBBox, false)
then stateSet indeed has some value. whats is the problem?
[/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=38572#38572
___
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] Meta-data in core OSG - project started
Hi Peter,
Okay, we'll certainely try your ideas. I guess ValueBase is meant to be
derived, but ValueT isn't.
However, I'm not sure I understand the immutable thing. Do you mean you
preference goes to
function( someParam )
rather than
function( ValueSomeType(someParam) )
?
If so, yes. And that's of course easier to write and read.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Peter Amstutz peter.amst...@tseboston.com a écrit :
You could use an implicit constructor, e.g.
templatetypename T
class Value {
Value(T);
Value(const ValueT);
};
class Valueint;
templateT
void addMeta(const std::string, const ValueT v) {
ValueT* localcopy = new ValueT(v);
}
so the function call:
addMeta(myMeta, 5);
is implicitly converted to:
addMeta(std::string(myMeta), Valueint(5));
Two considerations:
- There is some copying involved, which might be undesirable for
large
arrays. C++ 2011 move constructors are intended to solve this
problem
in general, but it's unlikely that OSG compatibility requirements
will
allow the use of C++ 2011 features for a while.
- The way it is described here, any customization for ValueT must
occur through template specialization, rather than subclassing. To
support subclassing, use a clone() method instead of new ValueT(v).
On a related note, my preference would be for the ValueT class to
be
immutable so that you are required to set metadata values through the
API rather than poking ValueT objects directly. This is necessary
if
you want to support alternate backing stores which don't use ValueT
objects in the backend at all.
- Peter
On 4/15/2011 11:10 AM, Sukender wrote:
Hi Peter,
Thanks... but what for the addMetaT()?
I mean it's okay having a addMeta(string, ValueBase *), but this
will force you to write
o-addMeta( myMeta, new Valueint(5) );
instead of simply
o-addMeta( myMeta, 5 );
which could be nice. Any idea?
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
--
Peter Amstutz
Senior Software Engineer
Technology Solutions Experts
Natick, MA
02131
___
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] Meta-data in core OSG - project started
hmmm...
Why did you write
templateT void addMeta(const std::string, const ValueT v);
?
Wouldn't this be simpler:
templateT void addMeta(const std::string, const T v);
?
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Peter Amstutz peter.amst...@tseboston.com a écrit :
You could use an implicit constructor, e.g.
templatetypename T
class Value {
Value(T);
Value(const ValueT);
};
class Valueint;
templateT
void addMeta(const std::string, const ValueT v) {
ValueT* localcopy = new ValueT(v);
}
so the function call:
addMeta(myMeta, 5);
is implicitly converted to:
addMeta(std::string(myMeta), Valueint(5));
Two considerations:
- There is some copying involved, which might be undesirable for
large
arrays. C++ 2011 move constructors are intended to solve this
problem
in general, but it's unlikely that OSG compatibility requirements
will
allow the use of C++ 2011 features for a while.
- The way it is described here, any customization for ValueT must
occur through template specialization, rather than subclassing. To
support subclassing, use a clone() method instead of new ValueT(v).
On a related note, my preference would be for the ValueT class to
be
immutable so that you are required to set metadata values through the
API rather than poking ValueT objects directly. This is necessary
if
you want to support alternate backing stores which don't use ValueT
objects in the backend at all.
- Peter
On 4/15/2011 11:10 AM, Sukender wrote:
Hi Peter,
Thanks... but what for the addMetaT()?
I mean it's okay having a addMeta(string, ValueBase *), but this
will force you to write
o-addMeta( myMeta, new Valueint(5) );
instead of simply
o-addMeta( myMeta, 5 );
which could be nice. Any idea?
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
--
Peter Amstutz
Senior Software Engineer
Technology Solutions Experts
Natick, MA
02131
___
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] OpenSceneGraph-2.9.12 tagged
Hi All, I have just tagged the OpenSceneGraph-2.9.12 release, I pushed this out before I dive into another round of handling osg-submissions as handling the submissions is likely to take me to the end of the week and possibly beyond. I intend to get 2.9.13 once we back up to date with submissions. Dev release page contains all the links: http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases The details are: OpenSceneGraph-2.9.12, released on 19th April 2011, key deliverables in this dev release are: Android support Improved Iphone and Ipad support DatabasePager and IncrementalCompileOperation improvements for better thread safety and ability to manage constant frame rates when paging A number of bug fixes and minor feature improvements/optimizations. source package : OpenSceneGraph-2.9.12.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.9.12 OpenSceneGraph Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] broken osgViewer header installation
Hi all, I have discovered that the installation of the osgViewer headers got broken with rev 12208 and 12231. These are part of the Android integration (which is a great addition btw) The old cmake code went through some extra hoops to rebuild the source tree structure in the installation step, e.g. GraphicHandleX11 went into CMAKE_INSTALL_PREFIX/include/osgViewer/api/X11/. This is important since GraphicsWindowX11 includes osgViewer/api/X11/GraphicsHandleX11, not osgViewer/GraphicsHandleX11 which is where it gets installed now. The reason that this hasn't been noticed is probably that the old headers are still installed to the correct place and still gets included. I'm suggesting to revert the old installation step only for platform specific header ( under include/osgViewer/api ) but keep other changes from 12208. cheers Mattias ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] broken osgViewer header installation
HI Mattias, Thanks for spotting this regression. Could you make the changes that fix the problem and post them to osg-submissions. I'm just emarking on a big osg-submissions purge so want to concentrate on this. Cheers, Robert. On Tue, Apr 19, 2011 at 12:13 PM, Mattias Helsing helsin...@gmail.com wrote: Hi all, I have discovered that the installation of the osgViewer headers got broken with rev 12208 and 12231. These are part of the Android integration (which is a great addition btw) The old cmake code went through some extra hoops to rebuild the source tree structure in the installation step, e.g. GraphicHandleX11 went into CMAKE_INSTALL_PREFIX/include/osgViewer/api/X11/. This is important since GraphicsWindowX11 includes osgViewer/api/X11/GraphicsHandleX11, not osgViewer/GraphicsHandleX11 which is where it gets installed now. The reason that this hasn't been noticed is probably that the old headers are still installed to the correct place and still gets included. I'm suggesting to revert the old installation step only for platform specific header ( under include/osgViewer/api ) but keep other changes from 12208. cheers Mattias ___ 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] Meta-data in core OSG - project started
On 4/19/2011 5:49 AM, Sukender wrote:
hmmm...
Why did you write
templateT void addMeta(const std::string, const ValueT v);
?
Wouldn't this be simpler:
templateT void addMeta(const std::string, const T v);
?
You're right, that is confusing. Here's a better way to compare the
alternatives:
templateT void addMeta(const std::string, const ValueT v) {
// Supports v as a subclass of ValueT
ValueT* localcopy = v.clone();
}
templateT void addMeta(const std::string, const T v) {
// Can only customize ValueT through template specialization
ValueT* localcopy = new ValueT(v);
}
--
Peter Amstutz
Senior Software Engineer
Technology Solutions Experts
Natick, MA
02131
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Immutable means cannot be changed. So I mean that the Value class
should not have a set method and all get methods should be const. E.g.
templateT
class Value {
private:
T v;
public:
Value(const T _v) : v(_v) { }
const T get() { return v; }
// type conversion operator, so you can write
// Valueint a(5);
// int b = a;
const T operator T () { return v; }
};
On 4/19/2011 5:46 AM, Sukender wrote:
Hi Peter,
Okay, we'll certainely try your ideas. I guess ValueBase is meant to be
derived, but ValueT isn't.
However, I'm not sure I understand the immutable thing. Do you mean you
preference goes to
function( someParam )
rather than
function( ValueSomeType(someParam) )
?
If so, yes. And that's of course easier to write and read.
--
Peter Amstutz
Senior Software Engineer
Technology Solutions Experts
Natick, MA
02131
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPPU] osgPPU with CompositeViewer
Hi, Has anyone been trying to use the osgPPU with CompositeViewer? I tried to run the same code i succesfully use with a regular viewer but it fails when i try to apply it to the second view. First view works fine but the second fails. Basically i'm just applying the processor to the view camera instead of the viewer camera. I would just like to know if someone has used it succesfully to make sure the problem is in my code :-) I am using the 0.4.0 version of osgPPU. Thank you! Cheers, Sami -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38587#38587 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] Need Efficient mesh data structures
Hi, depends on your requirements, for geometry processing i would recommend openmesh or vcg. VCG is part of the MeshLab tool on sourceforge. Its a bit harder to find. Google for vcglib. Hope this helps, Tim manish8892 wrote: Hi, I am looking for an efficient general mesh data structure. Having feature like Generating normal arrays and texture coordinate for model,Parameterization of Triangulated Surface Meshes ; texture mapping and that can easily integrate with OSG. I know some of them like : openMesh osgmodeling CGAL I need better solution which one is most suitable or there some other library which can be helpful to me. I had hoped that someone might have used it before. ... Thank you! Cheers, manish -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38589#38589 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] rewind imported animated model
Hi, in my program I load a file (a collada animation) then like in osganimationviewer example I make a AnimationManagerFinder structure, I set setPlayMode(osgAnimation::Animation::ONCE); and I play animation. This file is referenced by some objects but after I play for the first time the animation, if I try to restart the animation it stuck in last frame. Can you help me? thanks daniele -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38590#38590 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] I am back
thanks J-S .. What has happened in the last couple of months ? nick On Mon, Apr 18, 2011 at 5:46 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Nick, I am back :) ... this time from macedonia .. have you missed me?? Welcome back! J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] glCopyTexImage2D or Frame Buffer Object
Hello, Few month ago, I got an application, which realized a render to texture with glCopyTexImage2D(GL_TEXTURE_2D,0,...) and the antialiasing and the anaglyphic works well. Today I tried the render-to-texture with the frame buffer object as render target for the osg::Camera and in this case the antialiasing doesn't work. Also the anaglyphic view doesn't work. Why did antialiasing and anaglyphic work with glCopyTexImage2D? I have read that the frame buffer object doesn't support antialiasing, is it true? Thanks Martin -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] I am back
Hi Nick, thanks J-S .. What has happened in the last couple of months ? Well, the usual, a few dev releases, lots of submissions, the project moving forward at a steady pace :-) I'll let you have a look at the archives for more details :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] glCopyTexImage2D or Frame Buffer Object
Hello, I have the answer of the question what is different. Frame Buffer Object is render to texture. So the texture use the frame buffer and you render on it directly. Copy to texture means that the frame buffer is copy to the texture buffer after the rendering. I hope this is true. And if I copy it after the rendering I get the antialiasing and anagyphic features. Another question. What is better? Is the copy too slow with a texture resolution of 1400x1050? Thanks Martin Original-Nachricht Datum: Tue, 19 Apr 2011 16:30:19 +0200 Von: Martin Großer grosser.mar...@gmx.de An: osg-users@lists.openscenegraph.org Betreff: [osg-users] glCopyTexImage2D or Frame Buffer Object Hello, Few month ago, I got an application, which realized a render to texture with glCopyTexImage2D(GL_TEXTURE_2D,0,...) and the antialiasing and the anaglyphic works well. Today I tried the render-to-texture with the frame buffer object as render target for the osg::Camera and in this case the antialiasing doesn't work. Also the anaglyphic view doesn't work. Why did antialiasing and anaglyphic work with glCopyTexImage2D? I have read that the frame buffer object doesn't support antialiasing, is it true? Thanks Martin -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] FrameBufferObject problems on OSG 2.9.11
I've recently switched my application from 2.9.9 to 2.9.12 and now I'm having
FrameBufferObject problems (there seems to have been recent changes in this
area).
The problem can be replicated in osgprerender example with a few minor changes
(see attached). These changes simple recreate the viewer after hitting the
escape key rather than simply exiting the executable. These errors (constantly
displayed) started showing up once the viewer is displayed the second time:
Warning: detected OpenGL error 'invalid operation' at after RenderBin::draw(..)
I do not have this problem with OSG 2.9.9 and 2.9.10 but do have this problem
with 2.9.11 and 2.9.12 when using this same exact test program.
I'm running this version of osgprerender example with the --fbo option but I
believe this is the default option.
Are you sure that these FBOs are being created correctly in OSG = 2.9.10?
Paul Palumbo
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=38598#38598
/* OpenSceneGraph example, osgprerender.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include osg/GLExtensions
#include osg/Node
#include osg/Geometry
#include osg/Notify
#include osg/MatrixTransform
#include osg/Texture2D
#include osg/TextureRectangle
#include osg/Stencil
#include osg/ColorMask
#include osg/Depth
#include osg/Billboard
#include osg/Material
#include osg/AnimationPath
#include osgGA/TrackballManipulator
#include osgGA/FlightManipulator
#include osgGA/DriveManipulator
#include osgUtil/SmoothingVisitor
#include osgDB/Registry
#include osgDB/ReadFile
#include osgDB/WriteFile
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include iostream
// call back which creates a deformation field to oscillate the model.
class MyGeometryCallback :
public osg::Drawable::UpdateCallback,
public osg::Drawable::AttributeFunctor
{
public:
MyGeometryCallback(const osg::Vec3 o,
const osg::Vec3 x,const osg::Vec3 y,const
osg::Vec3 z,
double period,double xphase,double amplitude):
_firstCall(true),
_startTime(0.0),
_time(0.0),
_period(period),
_xphase(xphase),
_amplitude(amplitude),
_origin(o),
_xAxis(x),
_yAxis(y),
_zAxis(z) {}
virtual void update(osg::NodeVisitor* nv,osg::Drawable* drawable)
{
// OpenThreads::Thread::microSleep( 1000 );
const osg::FrameStamp* fs = nv-getFrameStamp();
double simulationTime = fs-getSimulationTime();
if (_firstCall)
{
_firstCall = false;
_startTime = simulationTime;
}
_time = simulationTime-_startTime;
drawable-accept(*this);
drawable-dirtyBound();
osg::Geometry* geometry = dynamic_castosg::Geometry*(drawable);
if (geometry)
{
osgUtil::SmoothingVisitor::smooth(*geometry);
}
}
virtual void apply(osg::Drawable::AttributeType type,unsigned int
count,osg::Vec3* begin)
{
if (type == osg::Drawable::VERTICES)
{
const float TwoPI=2.0f*osg::PI;
const float phase = -_time/_period;
osg::Vec3* end = begin+count;
for (osg::Vec3* itr=begin;itrend;++itr)
{
osg::Vec3 dv(*itr-_origin);
osg::Vec3 local(dv*_xAxis,dv*_yAxis,dv*_zAxis);
local.z() = local.x()*_amplitude*
sinf(TwoPI*(phase+local.x()*_xphase));
(*itr) = _origin +
_xAxis*local.x()+
_yAxis*local.y()+
_zAxis*local.z();
}
}
}
Re: [osg-users] I am back
heh :) . ok Nick On Tue, Apr 19, 2011 at 4:35 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Nick, thanks J-S .. What has happened in the last couple of months ? Well, the usual, a few dev releases, lots of submissions, the project moving forward at a steady pace :-) I'll let you have a look at the archives for more details :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Forked osgIntrospection to cppintrospection
Hi Alexandre, Sorry for not following the thread because of my client work and the coming plan for the OSG cookbook (not started at present, but will be on the way soon :-). 2011/4/19 Alexandre Quessy alexan...@quessy.net: For the name of the project, Mike Wozniewski and I think we need this project to be renamed cppintrospection to avoid a name clash with the former one, unless I am misled. We still use some old OSG that is packaged in Debian, and it contains a osgIntrospection library. I'm OK with the name cppintrospection as it could be used in many other projects to wrap c++ source codes. osgWrappers could be just an important but not necessary component of it, which demonstrates the functionalities of the introspection framework and shows how to use the wrappers in other languages and for reflection use. Also, I really want to avoid working with Subversion, as Git is much more fun to work with. It should be OK to use a more powerful source control utility in my opinion. But I just failed to checkout the cppintrospection project with tortoiseGIT this afternoon. Maybe it is because of my terrible network or there was some maintenances on the github website? :-) Those two issues are not really issues, after all. I would really like to collaborate with you, Wang Rui, and benefit from your future changes to this project. I don't plan to make any change to it, as I am only interested in seeing it packaged, especially for Debian GNU/Linux. I'll try to compile and make cppintrospection work on my Windows system these few days. After that I'll start to work on the cmake support and in the future, think of using the wrappers with SWIG to generate code for other languages like C# and Python. Don't wait for my contribution because I'm still busy in the following months. Cheers, Wang Rui ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Maybe I should have added that I'm running on Linux with a Quadro FX 5800 video card. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38601#38601 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] glCopyTexImage2D or Frame Buffer Object
Hi Martin, FBO's do support multi-sampling - but the setup is different from the frame buffer set up of multi-sampling, instead you you provide the settings when you call Camera::attach(). The relevant methods are: /** Attach a Texture to specified buffer component. * The level parameter controls the mip map level of the texture that is attached. * The face parameter controls the face of texture cube map or z level of 3d texture. * The mipMapGeneration flag controls whether mipmap generation should be done for texture.*/ void attach(BufferComponent buffer, osg::Texture* texture, unsigned int level = 0, unsigned int face=0, bool mipMapGeneration=false, unsigned int multisampleSamples = 0, unsigned int multisampleColorSamples = 0); /** Attach a Image to specified buffer component.*/ void attach(BufferComponent buffer, osg::Image* image, unsigned int multisampleSamples = 0, unsigned int multisampleColorSamples = 0); As for anaglyphic stereo, this is managed currently by osgUtil::SceneView for frame buffers where it sets up two traversals one for each eye, and sets up the color write mask to render the cyan and red for the left and right eye traverals. A straight render to texture Camera won't use this higher level feature, if you want to implement stereo within a render to texture camera you'll need to manage the left/right eye passes as a subgraph of the Camera, or have two Camera and share the same FBO. Robert. 2011/4/19 Martin Großer grosser.mar...@gmx.de: Hello, Few month ago, I got an application, which realized a render to texture with glCopyTexImage2D(GL_TEXTURE_2D,0,...) and the antialiasing and the anaglyphic works well. Today I tried the render-to-texture with the frame buffer object as render target for the osg::Camera and in this case the antialiasing doesn't work. Also the anaglyphic view doesn't work. Why did antialiasing and anaglyphic work with glCopyTexImage2D? I have read that the frame buffer object doesn't support antialiasing, is it true? Thanks Martin -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl ___ 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] glFlush and osg
Hi there, I have an issue with glFlush, and I don't know exactly if this is related to OSG. Basically, I have a very complicated scenegraph, whose drawables are my own classes derived from osg::drawable. So, they implement the drawImplementation, by using standard OpenGL rendering commands (basically vertex arrays). I had to put a glFlush() at the end of each drawImplmentation() to make it work correctly. I mean that, if I didn't, the drawing would be completely wrong, as if wrong normals were applied to lighting computations. But glFlush() should only flush the content of the command buffer to the graphic board. Am I worng? Furthermore, it does not behave wrongly on every graphic board, only some cards shows the problem (mine is a nVidia Quadro FX 2500M). What's even worse is that putting such calls slows down my application a lot (from 22 to 13 fps). So, I just wonder if it might be a problem related to OSG (since I mixed osg with direct OpenGL commands), or if it might be related to specific drivers of my graphic board. Thanks in advance, Gianluca P.S. = BTW, if I replaced glFlush() with a double call to glPointSize(), passing 3.0 and 1.0 in sequence as sizes (but without making any other call inbetween). It still works good, as if glFlush() was issued, but without the side effect of slowness. So, actually they act as a glFlush() in my code! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Hi Paul, I have just tried your modified osgprerender and can confirm that problems exists on my system as well. I don't the cause of the problem, my best guess right now would be something like inappropriate reuse of GL objects. Robert. On Tue, Apr 19, 2011 at 3:39 PM, Paul Palumbo paul1...@yahoo.com wrote: I've recently switched my application from 2.9.9 to 2.9.12 and now I'm having FrameBufferObject problems (there seems to have been recent changes in this area). The problem can be replicated in osgprerender example with a few minor changes (see attached). These changes simple recreate the viewer after hitting the escape key rather than simply exiting the executable. These errors (constantly displayed) started showing up once the viewer is displayed the second time: Warning: detected OpenGL error 'invalid operation' at after RenderBin::draw(..) I do not have this problem with OSG 2.9.9 and 2.9.10 but do have this problem with 2.9.11 and 2.9.12 when using this same exact test program. I'm running this version of osgprerender example with the --fbo option but I believe this is the default option. Are you sure that these FBOs are being created correctly in OSG = 2.9.10? Paul Palumbo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38598#38598 ___ 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] glFlush and osg
Hi Gianluca, There isn't much we can probably suggest given you are using a custom Drawable implementation. General comments would be that glFlush shouldn't affect the quality of the results, only the speed at which handled. Using glFlush forces the GL driver to pause the application thread calling GL to wait until all the commands and data in GL drivers' fifo buffer have been passed to the graphics card. glFlush doesn't itself change any OpenGL state so in principle should not effect results. Given glFlush shouldn't have the effect you are describing perhaps it's just co-incidence and that a threading issue in your application is causing problems. I would also suggest replacing your custom Drawable with code based on osg::Geometry, this may or may not be possible, but trying this would at least give you a test using code that others have access to, and is known to work. Robert. On Tue, Apr 19, 2011 at 4:03 PM, Gianluca Natale nat...@europe.altair.com wrote: Hi there, I have an issue with glFlush, and I don’t know exactly if this is related to OSG. Basically, I have a very complicated scenegraph, whose drawables are my own classes derived from osg::drawable. So, they implement the drawImplementation, by using standard OpenGL rendering commands (basically vertex arrays). I had to put a glFlush() at the end of each drawImplmentation() to make it work correctly. I mean that, if I didn’t, the drawing would be completely wrong, as if wrong normals were applied to lighting computations. But glFlush() should only flush the content of the command buffer to the graphic board. Am I worng? Furthermore, it does not behave wrongly on every graphic board, only some cards shows the problem (mine is a nVidia Quadro FX 2500M). What’s even worse is that putting such calls slows down my application a lot (from 22 to 13 fps). So, I just wonder if it might be a problem related to OSG (since I mixed osg with direct OpenGL commands), or if it might be related to specific drivers of my graphic board. Thanks in advance, Gianluca P.S. = BTW, if I replaced glFlush() with a double call to glPointSize(), passing 3.0 and 1.0 in sequence as sizes (but without making any other call inbetween). It still works good, as if glFlush() was issued, but without the side effect of slowness. So, actually they act as a glFlush() in my code! ___ 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] R: glFlush and osg
Thanks Robert, I'll try to replace my drawables with those provided by osg. Gianluca -Messaggio originale- Da: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Robert Osfield Inviato: martedì 19 aprile 2011 17:26 A: OpenSceneGraph Users Oggetto: Re: [osg-users] glFlush and osg Hi Gianluca, There isn't much we can probably suggest given you are using a custom Drawable implementation. General comments would be that glFlush shouldn't affect the quality of the results, only the speed at which handled. Using glFlush forces the GL driver to pause the application thread calling GL to wait until all the commands and data in GL drivers' fifo buffer have been passed to the graphics card. glFlush doesn't itself change any OpenGL state so in principle should not effect results. Given glFlush shouldn't have the effect you are describing perhaps it's just co-incidence and that a threading issue in your application is causing problems. I would also suggest replacing your custom Drawable with code based on osg::Geometry, this may or may not be possible, but trying this would at least give you a test using code that others have access to, and is known to work. Robert. On Tue, Apr 19, 2011 at 4:03 PM, Gianluca Natale nat...@europe.altair.com wrote: Hi there, I have an issue with glFlush, and I don't know exactly if this is related to OSG. Basically, I have a very complicated scenegraph, whose drawables are my own classes derived from osg::drawable. So, they implement the drawImplementation, by using standard OpenGL rendering commands (basically vertex arrays). I had to put a glFlush() at the end of each drawImplmentation() to make it work correctly. I mean that, if I didn't, the drawing would be completely wrong, as if wrong normals were applied to lighting computations. But glFlush() should only flush the content of the command buffer to the graphic board. Am I worng? Furthermore, it does not behave wrongly on every graphic board, only some cards shows the problem (mine is a nVidia Quadro FX 2500M). What's even worse is that putting such calls slows down my application a lot (from 22 to 13 fps). So, I just wonder if it might be a problem related to OSG (since I mixed osg with direct OpenGL commands), or if it might be related to specific drivers of my graphic board. Thanks in advance, Gianluca P.S. = BTW, if I replaced glFlush() with a double call to glPointSize(), passing 3.0 and 1.0 in sequence as sizes (but without making any other call inbetween). It still works good, as if glFlush() was issued, but without the side effect of slowness. So, actually they act as a glFlush() in my code! ___ 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] OSG-based excavator simulator
Hi all, I just wanted to give you guys a heads up about a prototype project we worked on lately, and which I think looks great. There's a video of it on our YouTube channel: http://www.youtube.com/user/vortexsim#p/u/1/RhJR0qQJfAQ (set it to 1080p if you can) We did that demo in 3 weeks (2 people for graphics and physics programming, one modeler for the excavator model). Quick list of effects specific to this project: - Normal mapping - Specular mapping - Reflection mapping - HDR (using osgPPU) - Soil uses hardware instancing for the many small rocks - Mound of earth uses vertex texture fetch to render the height field (displace vertices, calculate normals in vertex shader) - Dust particles rendered with soft particle technique (depth buffer test) to avoid hard edges It's the most GPU-intensive simulator we've ever done, and it looks great, and it's OSG-based, so I thought I'd show it to anyone who's interested. :-) While you're on our YouTube page you can have a look at the other cool things we've done in the past, the offshore and port crane simulators are recent projects and are very nice as well (and they use osgOcean :-) ). http://www.youtube.com/user/vortexsim#p/u/9/KBGr74TMTrU http://www.youtube.com/user/vortexsim#p/u/0/dZeQ-eBrBDk Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] clipping problem with PagedLODs--RESOLVED
Hi Robert. I actually did successfully get clip planes working with your help via this list in June of last year (in the same way that you explain below). My concern was that it did not seem to be working with PagedLOD models. However, it turned out that I was looking in the wrong place. The pagedLOD geometry was using a different vertex shader than I was expecting. This shader did not calculate gl_ClipVertex = gl_ModelViewMatrix * gl_Vertex; Now that I added this line to the vertex shader, the reuseable clip plans (as you suggest below) does indeed work with PagedLODs. Thanks, Jason -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Tuesday, April 19, 2011 1:33 AM To: OpenSceneGraph Users Subject: Re: [osg-users] clipping problem with PagedLODs Hi Jason, The wa that the OSG handles positional state like clip planes is pair the a specific modelview matrix with the positional state, the modelview matrix used in provided when the cull traversal encounters a positional state node like ClipNode, TexGenNode or LightSource, and the pairing is done such that there is only one posible modelview matrix per positional state, on per RenderStage basis. This approach ensures that clip planes, eye linear texgen and light sources all have a single place in space for rendering a whole stage, but it does mean you can't reuse a clip plane, eye linear tex gen, or light within on stage. The only ways to support multiple clip planes or other positional state is to dispense with the positional state nodes completely and have custom state attribute that binds a specific modelview matrix to that state and applies this before applying the state, but straight away after applying the state will need to restore the original modelview matrix. You will also need to geneate the specific modelview matrix somehow, a custom node like ClipNode might be approrpriate. How this all relates to what you have done I can't say, there is no way for me to comment as the code is infront of you not me. Robert. On Mon, Apr 18, 2011 at 11:48 PM, Jason Jerald ja...@dartforms.com wrote: I created two new classes: ClipNodeReused inherited from ClipNode, and ClipPlaneReused from ClipPlane (basically just overriding apply(osg::State)). These classes enable me to reuse the OpenGL clipping planes so that I can do more than the graphics hardware limit of 6-8 clipping planes. This has worked well. However, I recently discovered that some model files do not get clipped correctly. The only thing that I see is different about these files is that they contain PagedLODs. I am not sure of the details of LODs to know if some form of clipping (perhaps as part of some form of culling?) might be happening that is keeping my custom clipping from occurring. Have others been able to clip PagedLODs successfully? Any ideas what might be going wrong here? Thanks! 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] addSlave messup main cameras stateset
thank you for getting back robet, i agree that i didnt present all the code,
however its mostly standard from the examples.
one thing i ought to mention is that i am using osg with wxWidgets. I tried to
go back and look at the code and i found that even if i just add a new camera
it screws with the state set. In the handler function code below i print the
pointer before and after add slave. first time i get an address, second time
its null
Code:
osgViewer::Viewer *viewer = cloudglobals::rootFrame-osg_viewer;
switch(ea.getEventType())
{
case(osgGA::GUIEventAdapter::PUSH):
{
osg::StateSet *stateSet = viewer-getCamera()-getOrCreateStateSet();
osg::Point *pointState =
(osg::Point*)stateSet-getAttribute(osg::StateAttribute::POINT);
cout{{# {{pointState{{ ; // this is NOT NULL (how to add angular brkts for
cout?)
viewer-addSlave(new osg::Camera, false); // add slave camera to viewer
stateSet = viewer-getCamera()-getOrCreateStateSet();
pointState = (osg::Point*)stateSet-getAttribute(osg::StateAttribute::POINT);
cout{{pointState{{endl;
}
}
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=38610#38610
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Hi Paul,
On Tue, Apr 19, 2011 at 4:13 PM, Robert Osfield
robert.osfi...@gmail.com wrote:
I have just tried your modified osgprerender and can confirm that
problems exists on my system as well. I don't the cause of the
problem, my best guess right now would be something like inappropriate
reuse of GL objects.
I have checked 2.9.10 and also find it to work fine with the modified
osgprerender. I cleaned the test example up a bit so ensure we can
use the same options on each run through the viewer, modified example
attached.
I've done a diff between the FrameBufferObject.cpp and RenderStage.cpp
and found no diffrences of note, and even patched the svn/trunk with
the 2.9.10 versions and still get the same problems, so the problem
isn't related directly to FBO setup and usage. I also patched the
Texture.cpp and header, and despite the many differences still didn't
see any fix... I'll keep reverting changes till I spot the file that
is the root of the problem.
Robert.
/* OpenSceneGraph example, osgprerender.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include osg/GLExtensions
#include osg/Node
#include osg/Geometry
#include osg/Notify
#include osg/MatrixTransform
#include osg/Texture2D
#include osg/TextureRectangle
#include osg/Stencil
#include osg/ColorMask
#include osg/Depth
#include osg/Billboard
#include osg/Material
#include osg/AnimationPath
#include osgGA/TrackballManipulator
#include osgGA/FlightManipulator
#include osgGA/DriveManipulator
#include osgUtil/SmoothingVisitor
#include osgDB/Registry
#include osgDB/ReadFile
#include osgDB/WriteFile
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include iostream
// call back which creates a deformation field to oscillate the model.
class MyGeometryCallback :
public osg::Drawable::UpdateCallback,
public osg::Drawable::AttributeFunctor
{
public:
MyGeometryCallback(const osg::Vec3 o,
const osg::Vec3 x,const osg::Vec3 y,const osg::Vec3 z,
double period,double xphase,double amplitude):
_firstCall(true),
_startTime(0.0),
_time(0.0),
_period(period),
_xphase(xphase),
_amplitude(amplitude),
_origin(o),
_xAxis(x),
_yAxis(y),
_zAxis(z) {}
virtual void update(osg::NodeVisitor* nv,osg::Drawable* drawable)
{
// OpenThreads::Thread::microSleep( 1000 );
const osg::FrameStamp* fs = nv-getFrameStamp();
double simulationTime = fs-getSimulationTime();
if (_firstCall)
{
_firstCall = false;
_startTime = simulationTime;
}
_time = simulationTime-_startTime;
drawable-accept(*this);
drawable-dirtyBound();
osg::Geometry* geometry = dynamic_castosg::Geometry*(drawable);
if (geometry)
{
osgUtil::SmoothingVisitor::smooth(*geometry);
}
}
virtual void apply(osg::Drawable::AttributeType type,unsigned int count,osg::Vec3* begin)
{
if (type == osg::Drawable::VERTICES)
{
const float TwoPI=2.0f*osg::PI;
const float phase = -_time/_period;
osg::Vec3* end = begin+count;
for (osg::Vec3* itr=begin;itrend;++itr)
{
osg::Vec3 dv(*itr-_origin);
osg::Vec3 local(dv*_xAxis,dv*_yAxis,dv*_zAxis);
local.z() = local.x()*_amplitude*
sinf(TwoPI*(phase+local.x()*_xphase));
(*itr) = _origin +
_xAxis*local.x()+
_yAxis*local.y()+
_zAxis*local.z();
}
}
}
bool_firstCall;
Re: [osg-users] OSG-based excavator simulator
Hi J-S, 3 weeks with 2 developers!!! Now I really feel like a rookie! Cheers, Greg -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38612#38612 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG-based excavator simulator
Hi Greg, 3 weeks with 2 developers!!! Now I really feel like a rookie! Out of pure modesty, I have to admit we already had a lot of framework in place for heavy equipment simulation. Nevertheless, this vehicle and the graphical effects I listed were new and were done in that time span. I won't tell you how many hours a day we worked though! :-) It was a crazy project but we pulled it off. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG-based excavator simulator
Hello Jean-Sebastien, Congratulations on the visual quality, it's really good. I'm curious about the shadows, did you use OSG's shadow system for them? Cheers Eduardo On Tue, Apr 19, 2011 at 12:41 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi all, I just wanted to give you guys a heads up about a prototype project we worked on lately, and which I think looks great. There's a video of it on our YouTube channel: http://www.youtube.com/user/vortexsim#p/u/1/RhJR0qQJfAQ (set it to 1080p if you can) We did that demo in 3 weeks (2 people for graphics and physics programming, one modeler for the excavator model). Quick list of effects specific to this project: - Normal mapping - Specular mapping - Reflection mapping - HDR (using osgPPU) - Soil uses hardware instancing for the many small rocks - Mound of earth uses vertex texture fetch to render the height field (displace vertices, calculate normals in vertex shader) - Dust particles rendered with soft particle technique (depth buffer test) to avoid hard edges It's the most GPU-intensive simulator we've ever done, and it looks great, and it's OSG-based, so I thought I'd show it to anyone who's interested. :-) While you're on our YouTube page you can have a look at the other cool things we've done in the past, the offshore and port crane simulators are recent projects and are very nice as well (and they use osgOcean :-) ). http://www.youtube.com/user/vortexsim#p/u/9/KBGr74TMTrU http://www.youtube.com/user/vortexsim#p/u/0/dZeQ-eBrBDk Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ 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-based excavator simulator
Hello Eduardo, Congratulations on the visual quality, it's really good. I'm curious about the shadows, did you use OSG's shadow system for them? Yep, that's osgShadow::LightSpacePerspectiveShadowMapDB in action. There were some recent improvements to help with stability of the shadows, it's not perfect but it helped. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG-based excavator simulator
Hi, That looks great! What sky framework did you use? It looks a little bit like Simul trueSky... Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38617#38617 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
