[osg-users] NASA, Japan Release Most Complete Topographic Map of Earth

2009-07-01 Thread Maciej Krol
Good news everyone!

http://www.nasa.gov/home/hqnews/2009/jun/HQ_09-150_ASTER_Topographic_Map.html
http://news.bbc.co.uk/2/hi/science/nature/8126197.stm

Regards,
Maciej
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Outline Effect traversal crash

2009-05-22 Thread Maciej Krol
Hi Brian, Robert, all,

For object outlining I use cull callback that traverses node two times (its
a simple workaround for two pass techniques). I use well known technique
rendering back faces in wireframe (
http://en.wikipedia.org/wiki/Cel-shaded_animation) prior regular rendering.
It was mentioned several times on osg-users. To outline selected node You
just need to call node-setCullCallback(new OutlineCallback), there is no
need to tweak the scene graph structure. To change outline color You could
use emissive color tweaking on object material, J-S was mentioning it some
time ago
http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg21935.html

class OutlineCallback : public osg::NodeCallback
{
public:
OutlineCallback();

/** Line width for outline effect */
void setLineWidth(float lineWidth);
float getLineWidth() const;

/** Sets required states */
void resetStateSet();

virtual void operator()(osg::Node *node, osg::NodeVisitor *nv);

protected:

osg::ref_ptrosg::StateSet _stateSet;
};

OutlineCallback::OutlineCallback()
{
resetStateSet();
setLineWidth(3.0);
}

void OutlineCallback::resetStateSet()
{
if (!_stateSet)
_stateSet = new osg::StateSet;
osg::StateSet *ss = _stateSet.get();

ss-setRenderBinDetails(200, RenderBin);

ss-setMode(GL_LIGHTING, osg::StateAttribute::OFF |
osg::StateAttribute::OVERRIDE);
for (unsigned int unit=0;unit4;++unit)
ss-setTextureMode(unit, GL_TEXTURE_2D, osg::StateAttribute::OFF |
osg::StateAttribute::OVERRIDE);

osg::PolygonMode *polygonMode = dynamic_castosg::PolygonMode
*(ss-getAttribute(osg::StateAttribute::POLYGONMODE));
if (!polygonMode)
{
polygonMode = new osg::PolygonMode;
ss-setAttribute(polygonMode, osg::StateAttribute::ON);
}
polygonMode-setMode(osg::PolygonMode::BACK, osg::PolygonMode::LINE);

osg::CullFace *cullFace = dynamic_castosg::CullFace
*(ss-getAttribute(osg::StateAttribute::CULLFACE));
if (!cullFace)
{
cullFace = new osg::CullFace;
ss-setAttribute(cullFace, osg::StateAttribute::ON);
}
cullFace-setMode(osg::CullFace::FRONT);

osg::Depth *depth = dynamic_castosg::Depth
*(ss-getAttribute(osg::StateAttribute::DEPTH));
if (!depth)
{
depth = new osg::Depth;
ss-setAttribute(depth, osg::StateAttribute::ON);
}
depth-setFunction(osg::Depth::LEQUAL);
}

void OutlineCallback::setLineWidth(float width)
{
osg::LineWidth *lineWidth = dynamic_castosg::LineWidth
*(_stateSet-getAttribute(osg::StateAttribute::LINEWIDTH));
if (!lineWidth)
{
lineWidth = new osg::LineWidth;
_stateSet-setAttribute(lineWidth, osg::StateAttribute::ON);
}
lineWidth-setWidth(width);
}

float OutlineCallback::getLineWidth() const
{
osg::LineWidth *lineWidth = dynamic_castosg::LineWidth
*(_stateSet-getAttribute(osg::StateAttribute::LINEWIDTH));
return lineWidth ? lineWidth-getWidth() : 1.0;
}

void OutlineCallback::operator()(osg::Node *node, osg::NodeVisitor *nv)
{
if (nv-getVisitorType() == osg::NodeVisitor::CULL_VISITOR)
{
osgUtil::CullVisitor *cv = dynamic_castosgUtil::CullVisitor *(nv);
if (cv)
{
cv-pushStateSet(_stateSet.get());
traverse(node, cv);
cv-popStateSet();
}
}

traverse(node, nv);
}

Regards,
Maciej

2009/5/21 Robert Osfield robert.osfi...@gmail.com

 Hi Brian,

 It sounds like you may have hit upon a threading bug in the Outline
 effect.  Try changing the viewer threading mode to either
 SingleThreaded or  CullDrawThreadPerCamera, if this works then there
 is an threading issue with changing display lists or StateSet's at the
 same time that these objects are being rendered.  Changing the
 DataVariance to STATIC is the usually the best way to solve this, but
 you can also double buffer the problem structures.

 Robert.

 On Thu, May 21, 2009 at 5:29 PM, Brian Stewart jbstew...@pobox.com
 wrote:
  Hi,
 
  I switched my code around to where the model was being added from the
 main loop rather than the update traversal, and it was still crashing. On
 closer examination I noticed that the crashes were occurring during the
 render traversal, so I began to suspect the effect itself. When I replaced
 the effect with an instance of osgFX::Scribe, then everything worked
 correctly. So something was amiss in the Outline effect itself. I was using
 it only because I did not know about the Scribe effect, which is better for
 my purposes anyway.
 
  Thank you!
 
  Brian
 
  --
  Read this topic online here:
  http://forum.openscenegraph.org/viewtopic.php?p=12692#12692
 
 
 
 
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 ___
 osg-users mailing list
 

Re: [osg-users] Repost: Top 10 debugging tips

2009-05-12 Thread Maciej Krol
Hi Simon, Paul et al,

Yesterday I've posted to osg-submissions notification redirection interface.
For windows you could redirect messages to debug output with single line of
code.

osg::setNotifyHandler(new osg::WinDebugNotifyHandler)

You can define custom notification sinks by implementing osg::NotifyHandler
interface:

class MyNotifyHandler : public osg::NotifyHandler
{
  void notify(osg::NotifySeverity severity, const char *message)
  {
 printf(severity %d: %s, severity, message);
  }
}

Apart from visual studio debugger output I use DebugView
http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx all the time,
it is a little tool from SysInternals (now Microsoft) that shows debug
messages from all applications. Very handy when You try to solve problems
with released application at target system and no debugger is available.

Regards,
Maciej

2009/5/13 Simon Hammett s.d.hamm...@googlemail.com

 Many, (most?) osg users are using windozes.
 So redirecting osg::notify messages should be in that list.

 (Plz somebody give me a job developing for *ix.!)

 2009/5/12 Paul Martz pma...@skew-matrix.com:
  I've created the following list of debugging tips to help new OSG
 developers
  become productive faster:
http://www.skew-matrix.com/bb/viewtopic.php?f=6t=5
 
  I hope you find it useful. Feedback appreciated.
 
  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
 
 



 --
 http://www.ssTk.co.uk
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




-- 
Regards,
Maciej Krol
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] VirtualProgram - making programmable pipeline less fixed

2009-05-11 Thread Maciej Krol
Hi Wojtek, J-S et al,

Thanks for sharing the code Wojtek. It is always nice to see production code
that does the job. What a coincidence, right now I am experimenting with
embedding custom modes (including Your osgShadow) and shader composition
directly in a cull traversal. Definitely I will take a look at Your code.
IMO the ubershader is not the way to go, OSG should focus on more
distributed approaches like the one You presented.

I wrote StateEx in ShaderGen to get access to protected members of
osg::State. In the past osg::State was not used outside of cull/render
stages. Since shaders came into play it is more often abused :).

Regards,
Maciej

2009/5/11 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com

 Hi Wojtek,

  I am glad I have Your support. Honestly, I was counting on You ;-) I am
 not that fluent in English as I would like to be. Writing such posts usually
 take me much longer than in may native polish, I often realize that some
 ideas got lost in the midle of batlle with proper word/expression selection,
 so its always good to have some support from native speakers ;-).


 Actually my native language is French, but I learned English at a very
 young age so I'm pretty fluent. Thanks for the compliment, I'm glad to help
 and when the functionality is something I've wanted for a while I'm even
 more glad! :-)

  Look at StateHack class and reinterpret_castStateHack expression in
 VirtualProgram apply.


 Wow, how did I miss that? :-)

  StateHack overrides osg::State class to make getAttribureVec method
 accessible to Virtual program. This method is protected or private to
 osg::State.
 Obiously this could be solved by mamking VirtualProgram a friend of
 osg::State but that would require changes to core OSG.


 I've actually seen such a class a few times in the past few months (one in
 the osgUtil::ShaderGen class (cpp file, class called StateEx). That, to me,
 means that perhaps the osg::State API isn't as flexible as it could be (or
 perhaps it was ok in the past but now it needs to be evolved in new
 directions). Robert, any comments on this?

 Obviously exposing osg::State's internals wholesale would make it easy for
 users to muck things up, but two cases of overriding it to provide access to
 some of its private/protected methods/data tells me that it might be nice to
 think about a cleaner way to provide this access? In both cases, the methods
 are just getters so perhaps they could be safely added to the API (or in a
 slightly modified mode)?

 Hoping to see this move forward,


 J-S
 --
 __
 Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.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] Web 3D opensource solution by Google ?

2009-05-11 Thread Maciej Krol
Hi Robert,

Google is promising great performance from V8 JavaScript engine
http://code.google.com/p/v8. It was created with embedding in mind. It would
be great to write node update callbacks in JavaScript or Lua.

Regards,
Maciej

2009/5/11 Robert Osfield robert.osfi...@gmail.com

 Hi Pierre,

 Thanks for the links.  Just had a quick browse, it's amusing to find
 some OpenSceneGraph terminology turn up in their technology
 overview... StateSet, RenderGraph anyone, coincidence or inspiration
 :-)

 Lightweight javascript scene graph will have some value for browsers.
 It's unlikely to scale well to complex graphics apps and data sizes.
 When Google announced this effort it did make think about whether a
 JavaScript wrapper for the OSG might just be an decent alternate
 solution for those who need real power and scalability.

 Another thought I've had is for the future of Present3D to migrate to
 be script driven, with the scripting sitting upon a high level
 abstraction of the various assets you have in the scene.  One could
 possible select JavaScript ontop of this high level abstraction,
 although personally I'm inclined towards Lua for it's ease of
 integration.  In the context of browsers JavaScript is king though...

 Robert.


 On Mon, May 11, 2009 at 3:01 PM, Pierre Bourdin (gmail)
 pierre.bour...@imerir.com wrote:
  Hi all,
 
  have you seen this project ?
  http://code.google.com/intl/fr/apis/o3d/
 
  http://code.google.com/intl/fr/apis/o3d/docs/techoverview.html
 
  Here's an interview about it...
  http://www.3d-test.com/interviews/google_O3D_1.htm
 
  What's your opinion about this project ?
  Pierre.
  
  Pierre BOURDIN
  I.M.E.R.I.R.
  Av. Pascot BP 90443
  66004 PERPIGNAN
  tél: 04 68 56 84 95
  fax: 04 68 55 03 86
  email: bour...@imerir.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

___
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

2009-03-03 Thread Maciej Krol
Hi Roland,

I am glad that someone is digging this subject. I wrote simple visitor that
generates shaders from accumulated state sets. Custom state mask (int) is
extracted from stateset (LIGHT, FOG, DIFFUSE_MAP, NORMAL_MAP, etc). Based on
this mask  shaders are generated and attached to drawables. Shaders
are cached so there is only a few of them.

Right now I am quite busy at work. I will refactor my code to strip out
customer specific stuff. I hope today late evening (Europe) I will send you
working code.

Regards,
Maciej


2009/3/3 Roland Smeenk osgfo...@tevs.eu

 Mike,

 I know of shadergen. It was already mentioned earlier in this thread. It
 will come in handy when recreating the ffp functionality in shaders.
 I am interested in existing osg code that does shader generation based on
 the osg state.

 --
 Roland

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=7885#7885





 ___
 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] Fixed function pipeline - GLSL shaders

2009-02-23 Thread Maciej Krol
Hi Robert et al,

I thought about concept of generating shader code in cull traversal from
shader snippets. Snippet is a piece of GLSL code that implements certain
functionality like texture sampling or lighting, usually few lines of code.
Snippets have defined inputs like required varyings, uniforms and output
variables of dependant snippets. Output of snippet is a glsl variable (i.e.
texture coordinate, texture color) for internal snippet or
gl_FragColor/gl_FragData for terminal snippet. Snippets sit in a StateSet
just like modes and attributes. In cull traversal dependency graph of
snippets is created. From this graph GLSL program is generated or fetched
from cache. This approach would allow to seamlessly use functionality from
different toolkits without the need to rewrite shaders or to use ubershader.
Toolkits such as osgShadow or osgFX would expose shader snippets for certain
effects (shadow, phong lighting, atmospheric fog, etc) which could be merged
into snippet dependency graph. To imlement fixed function pipeline
functionality one can define mapping from modes/attributes to snippets. It
is just a concept. I do not know would it work in terms of ease of use and
extensibility.

GLSL is a must in these days especially for one reason - per pixel lighting.
It is a pity that it is not exposed in a fixed function pipeline. In my
applications I map fixed function pipeline to GLSL with custom visitor.
Based on state set modes (lighting, fog, ...) and vertex attributes (normal,
tangent, texco, ...)  GLSL shaders are generated and cached in a map (modes,
vertAttribs)=shader so they are unique. Only certain cases of FFP are
handled. Visitor is called in ReadFileCallback to convert FFP to GLSL. In
typical scenario You need only a few unique shaders (light on/off, color map
on/off, normal map on/off, env map on/off, fog on/off). Such simple solution
really pays off in visual quality of scenes.

Regards,
Maciej

2009/2/20 Robert Osfield robert.osfi...@gmail.com

 Hi All,

 One of the items I have ticking away as a background process is the
 topic of how we should gracefully manage the transition from the usage
 of fixed function pipeline to entirely shader based implementations.
 One motivation is the obvious one - GL3 and OpenGL ES don't have any
 fixed function pipeline, so we need to know how to implement the
 current OSG functionality that relies upon fixed function pipeline,
 and a second more subtle one - how to manage the combination of
 different shaders in a way that is as flexible and intuitive as the
 fixed function pipeline is for composing different elements of state
 together.

 This isn't an easy problem to solve, and rather than try to come up
 with a complete solution right now, in tinkering round the edges
 trying to get a better picture of the landscape of the problem.  One
 area we can map out right now is that of how existing fixed function
 pipeline features would map to GLSL shaders.  I recall that such a
 mapping has been published, but a quick search on the web didn't pin
 point it.  Does anyone have a reference to such a body of work?

 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] Fixed function pipeline - GLSL shaders

2009-02-23 Thread Maciej Krol
Hi Robert,

I think shader composition would be the next big thing for OSG although
robust design is far from trivial. For most users hiding shaders or
snippets would be the good thing. I would love to have state sets with OSG
modes not GL ones i.e.

StateSet
{
  OSG_LIGHTING ON
  osgLightingModel {
mode PHONG
  }
  OSG_NORMAL_MAP ON
  OSG_SHADOW ON
  OSG_FOG ON
  osgFogModel {
 mode VOLUMETRIC
 upDir 0 0 1
  }
}

Power user could register ther own modes/attributes handled by external
toolkits. With this approach different backends for GL1, GL2, GL3, GLES,
Sofware rasterizer, Software raytracer, DirectX :) could be implemented.

Regards,
Maciej


2009/2/23 Robert Osfield robert.osfi...@gmail.com

 HI Marciej,

 You thoughts on shader snippets being collected and assembled into
 programs that are then cached is roughly what I've been envisaging as
 well.  It's something I did try to get my head around when we
 integrated GLSL into the core OSG a few years back, but the complexity
 of this system meant that much more time would have to be invested in
 developing, so rather than be so ambitious we went for the current
 approach of decoupling uniforms from osg::Program, but not the whole
 hog of decoupling osg::Shader from osg::Program.

 The full blown shader composition is something we do need to address
 in the next generation of the OSG.  Exactly what the interface should
 be, and how we implement the back-end is the big hard part.  Once we
 have such a scheme in place then provided only fixed function style
 capabilities in GL3 or GL2 GLSL path ways should be much easier.  At
 this point the distinction between the fixed function pipeline and
 shader pipeline will melt away and become an implementation detail,
 rather than a scene graph interface one.

 Robert.

 On Mon, Feb 23, 2009 at 10:04 AM, Maciej Krol mack...@gmail.com wrote:
  Hi Robert et al,
 
  I thought about concept of generating shader code in cull traversal from
  shader snippets. Snippet is a piece of GLSL code that implements certain
  functionality like texture sampling or lighting, usually few lines of
 code.
  Snippets have defined inputs like required varyings, uniforms and output
  variables of dependant snippets. Output of snippet is a glsl variable
 (i.e.
  texture coordinate, texture color) for internal snippet or
  gl_FragColor/gl_FragData for terminal snippet. Snippets sit in a StateSet
  just like modes and attributes. In cull traversal dependency graph of
  snippets is created. From this graph GLSL program is generated or fetched
  from cache. This approach would allow to seamlessly use functionality
 from
  different toolkits without the need to rewrite shaders or to use
 ubershader.
  Toolkits such as osgShadow or osgFX would expose shader snippets for
 certain
  effects (shadow, phong lighting, atmospheric fog, etc) which could be
 merged
  into snippet dependency graph. To imlement fixed function pipeline
  functionality one can define mapping from modes/attributes to snippets.
 It
  is just a concept. I do not know would it work in terms of ease of use
 and
  extensibility.
 
  GLSL is a must in these days especially for one reason - per pixel
 lighting.
  It is a pity that it is not exposed in a fixed function pipeline. In my
  applications I map fixed function pipeline to GLSL with custom visitor.
  Based on state set modes (lighting, fog, ...) and vertex attributes
 (normal,
  tangent, texco, ...)  GLSL shaders are generated and cached in a map
 (modes,
  vertAttribs)=shader so they are unique. Only certain cases of FFP are
  handled. Visitor is called in ReadFileCallback to convert FFP to GLSL. In
  typical scenario You need only a few unique shaders (light on/off, color
 map
  on/off, normal map on/off, env map on/off, fog on/off). Such simple
 solution
  really pays off in visual quality of scenes.
 
  Regards,
  Maciej
 
  2009/2/20 Robert Osfield robert.osfi...@gmail.com
 
  Hi All,
 
  One of the items I have ticking away as a background process is the
  topic of how we should gracefully manage the transition from the usage
  of fixed function pipeline to entirely shader based implementations.
  One motivation is the obvious one - GL3 and OpenGL ES don't have any
  fixed function pipeline, so we need to know how to implement the
  current OSG functionality that relies upon fixed function pipeline,
  and a second more subtle one - how to manage the combination of
  different shaders in a way that is as flexible and intuitive as the
  fixed function pipeline is for composing different elements of state
  together.
 
  This isn't an easy problem to solve, and rather than try to come up
  with a complete solution right now, in tinkering round the edges
  trying to get a better picture of the landscape of the problem.  One
  area we can map out right now is that of how existing fixed function
  pipeline features would map to GLSL shaders.  I recall that such a
  mapping has been published, but a quick

Re: [osg-users] forcing a square aspect ratio

2009-02-11 Thread Maciej Krol
Hi Cory,

I have similar problem in osgviewerWX. Initial aspect ratio should be
computed from client rectangle of viewer window, but currently it is
computed from window rectangle of main frame. Client rectangle is not known
until first resize event. The solution would be to postpone viewer
initialization until we got valid window size, but I haven't tried this yet.
IMHO it is too much hassle only to have square aspect ratio.

As far as I remember when window is resized aspect ratio is only rescaled
instead of being recalculated, so initial invalid aspect propagates. IMHO
the right solution is to add computation of square aspect ratio directly
into viewer resize functionality. Any suggestions how to do it?

Regards,
Maciej

2009/2/11 Robert Osfield robert.osfi...@gmail.com

 Hi Cory,

 I'm not personally familiar with the osgviewerMFC example as I'm don't
 have windows here.  I general I'd point the figure at the way the
 window and associated cameras are initialized, clearly it must being
 setup without the correct aspect ratio. Have a look at the other
 examples that use window inheritance when setting up the
 GraphicsWindows such as osgviewerQT and osgviewerWX.

 Robert.

 On Tue, Feb 10, 2009 at 8:48 PM, Cory Riddell c...@codeware.com wrote:
  FWIW, I've attached a screen shot of what should be a square. The
 Drawable
  code was taken from the quickstart guide and the vertices are:
  v-push_back(osg::Vec3(-1.f, 0.f, -1.f));
  v-push_back(osg::Vec3(1.f, 0.f, -1.f));
  v-push_back(osg::Vec3(1.f, 0.f, 1.f));
  v-push_back(osg::Vec3(-1.f, 0.f, 1.f));
  Any ideas?
 
 
 
 
  Cory Riddell wrote:
 
  I've been playing with osgviewerMFC and I've noticed that when I open an
  osg file (like cow.osg), the rendering is stretched to fit the aspect
  ratio of the containing window. For example, if I resize the app to be
  wide then open the cow, I get a very long cow. If I make the window
  short and tall then open the cow, I get a very compressed cow. Resizing
  the window does resize the cow, but the aspect ratio doesn't change.
 
  osgviewerQT doesn't have this problem but I don't see what's different.
 
  What controls the aspect ratio of the rendering?
 
  BTW, my cow.osg is from 2.6. Has the osg file format changed?
 
  Cory
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Callback when loading nodes in the database pager

2008-12-19 Thread Maciej Krol
Hi Ralf, Christophe

We use ReadFileCallback to modify requested nodes from database pager. It
works fine, but make sure Your code is thread safe.

Regards,
Maciej

2008/12/18 christophe loustaunau christophe.loustau...@gmail.com

 Hi Ralf,

 look at ReadFileCallback in the example osgCallBack, it may be what you
 wan't.

 Regards.

 On Thu, Dec 18, 2008 at 2:20 PM, Ralf Stokholm alfma...@arenalogic.comwrote:

 Hi List

 Is it possible to attach a callback to handle/modify loaded nodes in the
 database thread?

 Background:

 We are using VPB generatet terrain database in a delta3d application, to
 get the terrain mesh into our simulation we are using a cull visitor which
 takes care of loading loading and removing collision meshes from the physics
 engine when the accociatet node is generatet and removed.

 Even though this approach works well, it is rather slow and it annoys me
 that I have to dublikate bookkeeping which must already be implementet in
 the databasepager. I would also like to put the work in the database thread
 when possible.

 Is there any callbacks or similar for plugging in this code at the moment?

 Brgs.

 Ralf Stokholm.
 www.arenalogic.com

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




 --
 Christophe Loustaunau.

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




-- 
Regards,
Maciej Krol
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] [osgAL] Link error in release

2008-12-16 Thread Maciej Krol
Hi,

Latest trunk of osgAL compiles cleanly with OSG 2.7.7.

Regards,
Maciej

2008/12/17 Anna Sokol annaso...@gmail.com

 Hi Sukender,

  unresolved external symbol unsigned int __thiscall
  OpenThreads::Atomic::operator++()
  referenced in function osg::ref_ptrosgDB::DotOsgWrapper 
 osg::ref_ptrclass
  osgDB::DotOsgWrapper::operator=(osgDB::DotOsgWrapper *)

 The above error occurs because OpenThreads is not included in the
 library dependencies for osgAL.
 This didn't cause any errors with osg2.4 but did cause compile errors
 with osg2.6. and osg2.6.1 .
 By including OpenThreads library dependency the compile errors went
 away with osg2.6 and osg2.6.1 .
 I haven't tried to compile with osg2.7.x or the osg SVN. There might
 be additional incompatibilities there.
 I used Microsoft Visual Studio 2005 to compile.
 Hope this helps.

  - Anna
 ___
 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] Compressed osg::Image not a power of two in earth_bayarea database

2008-12-14 Thread Maciej Krol
Hi Robert et al,

I am testing http://www.openscenegraph.org/data/earth_bayarea/earth.ive on
almost seven years old PC (Athlon 1700+, 256 MB RAM, GeForce 4MX 64MB,
WinXP). I must say it runs just fine with a decent framerate. The only
problem that I have is that when I zoom into bay area textures of some of
the higher LODs (level 7, but not the highest ones) are displayed in white.
In console I get following message Warning:: Compressed osg::Image not a
power of two, cannot apply to texture.

Regards,
Maciej
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Compressed osg::Image not a power of two in earth_bayarea database

2008-12-14 Thread Maciej Krol
Thanks Robert,

I was afraid that it's a bug, not a feature :)

Regards,
 Maciej

2008/12/14 Robert Osfield robert.osfi...@gmail.com

 Hi Maciej,

 On Sun, Dec 14, 2008 at 10:32 AM, Maciej Krol mack...@gmail.com wrote:
  Hi Robert et al,
 
  I am testing http://www.openscenegraph.org/data/earth_bayarea/earth.iveon
  almost seven years old PC (Athlon 1700+, 256 MB RAM, GeForce 4MX 64MB,
  WinXP). I must say it runs just fine with a decent framerate. The only
  problem that I have is that when I zoom into bay area textures of some of
  the higher LODs (level 7, but not the highest ones) are displayed in
 white.
  In console I get following message Warning:: Compressed osg::Image not a
  power of two, cannot apply to texture.

 Looks like your hardware doesn't support non power of two textures.
 This databases has been built for absolute minimum footprint and
 bandwidth so takes advantage of non power of two textures, but does
 mean that it's not compatible with older hardware.

 VPB by default doesn't right now enable the non power of two texture
 database build so will be compatible with older hardware, it's only
 when you turn on all the features for cutting down the database size
 that you'll have problems.

 Robert.
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




-- 
Regards,
Maciej Krol
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] If I want to use wxWidgets with OSG, do I need a particular version of wxWidgets?

2008-10-29 Thread Maciej Krol
Hi Ed,

I am using 2.8.7, but the latest stable version should work as well.

Regards,
Maciej

2008/10/29 Ed [EMAIL PROTECTED]

 If I want to use wxWidgets with OSG, do I need a particular version of
 wxWidgets?
 Ed

 ___
 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] Creating custom wrappers for osgIntrospection

2008-08-22 Thread Maciej Krol
Hi Mike,

http://osgscenemaker.googlepages.com
http://orihalcon.jp/orihalconfw

Regards,
 Maciej

2008/8/22 Mike Wozniewski [EMAIL PROTECTED]

 Actually, nevermind about genwrapper.

 I've managed to use the latest svn version to create custom wrappers for my
 classes (yay). Now what I would like to do, is to build a scene-graph editor
 GUI to edit my class properties.

 Details:

   * I particularly like wxWidgets and gtk.
   * The editor doesn't need to render the scene in the same process
 (for now). All I need is a tree-view of the scene, with panels
 that open when a particular node is clicked.
   * I would like to be able to choose what types of nodes appear in
 the tree-view. Only my custom nodes and a small subset of osg
 nodes (eg, osg::Group, osg::PositionAttitudeTransform, and a
 couple others) should appear.
   * Must rely on osgIntrospection and osgWrappers generated by
 genwrapper... I was excited about osgedit, until I realized that
 it uses some other (custom) reflection mechanism.


 Does anyone have some simple examples? Are there any libraries that use
 osgWrappers  osgIntrospection to provide a GUI?

 Thanks in advance for any pointers,
 -Mike



 Robert Osfield wrote:

 HI Mike,

 I'll have to defer to the osgInttrospection/genwrapper author Marco
 Jez for low level questions about the wrappers.  Hopefully he'll spot
 this this thread and comment.

 Robert.

 On Thu, Aug 21, 2008 at 4:10 PM, Mike Wozniewski [EMAIL PROTECTED]
 wrote:


 Thanks Robert.

 However, I think that genwrapper is not going to work for me. My source
 tree
 does not look enough like OSG, and I also have some custom types in my
 classes that genwrapper doesn't know about.

 I'm wondering if I can call introspection macros by hand? (I don't have
 too
 many to do).

 For example, I'd like to reflect my class asReferenced, so I've come up
 with
 something like this:
 BEGIN_OBJECT_REFLECTOR(asReferenced)
  I_BaseType(osg::Referenced);
  I_Constructor1(IN, t_symbol *, initID, Properties::NON_EXPLICIT,
 signature0, , );
  I_Method1(void, setParent, IN, t_symbol *, parent,
 Properties::NON_VIRTUAL, signatureA, , );
  I_Method0(t_symbol *, getParent, Properties::NON_VIRTUAL, signatureB,
 ,
 );
  .
  .
 END_REFLECTOR

 But what to put for signatures? Is there a way to automatically generate
 these?

 Thanks again,
 -Mike




 Robert Osfield wrote:


 Hi Mike,

 I've been updating the svn version of genwrapper, so grab svn/trunk if
 you want the latest.  I'll will update the tarball as well.

 Robert.

 On Wed, Aug 20, 2008 at 9:06 PM, Mike Wozniewski [EMAIL PROTECTED]
 wrote:



 Hi,

 I have custom classes which extend OSG classes, and I'd like to create
 wrapper libraries for use with osgIntrospection. Particularly, I'd like
 to
 use these wrappers to call my custom methods from a GUI that doesn't
 need
 to
 know a lot about the classes.

 I've found something called GenWrapper
 (http://www.openscenegraph.org/projects/osg/wiki/GenWrapper), but it
 seems
 to be quite old, pre-dating OSG 2.x.

 Does anyone have some sample code that creates wrapper libraries?

 Furthermore, does anyone have examples of custom classes which use
 osgIntrospection? ... I'm having a hard time understanding the
 reflection
 mechanism in OSG. Any examples would be appreciated.

 Also, I'd like to be compatible with both Linux and OSX.

 Thanks in advance,
 Mike Wozniewski
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org

 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org

 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Qt + non-continuous draw + pagedLOD: Random loss of detail??

2008-08-02 Thread Maciej Krol
Hi all,

I have the same problem in our digital content creation tool. IMHO the
plausible solution would be to expire the nodes after certain number of
frames rather than period of time. This would require changes in the
database pager. It shall be possible to select expiration mode - time based
or frame based (i.e. osgDB::setExpiryMode). I will think about
implementation details this weekend.

Regards,
 Maciej Krol

2008/7/31 Jakob Ruhe [EMAIL PROTECTED]

 Hi John!

 I also have these kind of problems when I use lazy rendering which
 is the way I want it to be done in my application.

 These methods may help you:
 osgDB::setExpiryDelay
 PagedLOD::setNumChildrenThatCannotBeExpired

 You can also override these virtual methods to fine tune what you want to
 do:
 osgDB::removeExpiredSubgraphs
 PagedLOD::removeExpiredChildren

 I hope it can help you in your case even though these are not any good
 permanent solutions for any lazy rendering app..

 /Jakob Ruhe

 2008/7/30 Glenn Waldron [EMAIL PROTECTED]:
  John,
 
  I have run into the same issue. PagedLOD children expire after a
 certain
  period of time (default is something like 5 seconds?) If a PagedLOD child
  has not been visited in the last N seconds, the pager will discard it and
  revert to a lower LOD. OSG updates the time-last-visited during the
 cull
  traversal in order to check for expiration. So, if you are not
 continuously
  running the frame loop, PagedLOD's will think their children have expired
  and will drop to the lowest LOD.
 
  I used to refer to the technique you're using as lazy rendering (i.e.
 only
  render a frame when something has changed) ... try searching the archives
  ... but at the time I never did find a good way to do this in OSG without
  confusing the pager.
 
  Glenn
 
  --
  Glenn Waldron : Pelican Mapping : http://pelicanmapping.com :
  +1.703.652.4791
 
  On Wed, Jul 30, 2008 at 8:39 AM, John Vidar Larring 
 [EMAIL PROTECTED]
  wrote:
 
  Hi all,
 
  Background:
  ---
  In our application the user can set up scenes ( or sequences as we call
  them) for playback on a timeline (e.g. seq.1 - transition - seg.2 -
  transition ... seq.N). Some scenes are too complex to render real-time
 and
  are recorded to movies before playback. Hence, when scenes are edited by
 the
  user all scenes are redrawn as needed rather than continuously to avoid
  sluggish GUI response.
 
  Problem:
  
  _Sometimes_ when the scene is redrawn in edit mode (i.e. redraw only if
  needed), the pagedLOD DB (osgTerrain) drops to the lowest detail level
 (Ref.
  osg_original.jpg and osg_problem.jpg). This behavior seems to appear at
  randomly. In playback mode (i.e. when frame rate is constant) the
 problem
  never occurs.
 
  Reproduce / Code example:
  --
  The problem has been reproduces in a small test program
  (osgtest_source_code.tgz) derived from the osgviewerQT example (since we
 are
  using Qt 4.x in our application). To reproduce: run the compiled
  application: 'osgtest -t your osgTerrain db' . To trigger refreshes,
  occlude parts of the window with another window. The problem typically
  reveals itself when at a redraw or when the window looses focus (be
 patient,
  since this happens randomly it may take some time before the problem
  occurs).
 
  Since I'm still quite new to OSG, I'm not sure where to look for a
  solution. Hopefully someone will spot the obvious error in the sample
 code.
  Any advice is highly appreciated.
 
  Versions:
  -
  OSG svn rev 8700
  Qt 4.2.3
 
  Best regards,
  John Larring
 
  --
  This message has been scanned for viruses and
  dangerous content by MailScanner, and is
  believed to be clean.
 
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] ref_ptr, ptr and leaking question (quite simple)

2008-07-26 Thread Maciej Krol
Hi Sam,

Constructor of osg::Geode does not increment ref count, since objects can be
allocated either on heap or stack.
The osg::ref_ptr manages ref count of object. Ref count is incremented in
constructor or assignment operator of ref_ptr and decremented in its
desctructor.

osg::Geode *g = new osg::Geode; // refCount = 0, object constructor does not
increment refCount
viewer.setSceneData(g) // refCount = 1, scene data is a osg::ref_ptr

Object ref count is managed starting from first osg::ref_ptr assignment.
Your code is OK until You are sure that the osg::Geode *g will be assigned
to osg::ref_ptr. Better solution is to manage Your objects as soon as
possible.

osg::ref_ptrosg::Geode g = new osg::Geode; // refCount = 1
viewer.setSceneData(g.get()); // refCount = 2

Keep track of osg::ref_ptr scoping. For example in factory functions ref_ptr
can destroy object.

osg::Geode *createGeode(...)
{
osg::ref_ptrosg::Geode g = new osg::Geode; // refCount = 1
...
return g.get()
// refCount = 0 g is destroyed
}

The solution is to avoid ref_ptr in this function or return ref_ptr instead.

osg::ref_ptrosg::Geode createGeode(...)
{
   osg::ref_ptrosg::Geode g = new osg::Geode; // refCount = 1
...
return g;
// refCount = 2 g is assigned to result ref_ptr
// refCount = 1 g is destroyed
}

Regards,
Maciej Krol

2008/7/26 Ariasgore [EMAIL PROTECTED]

 Hello,
 I have some novoice question about the use of pointers as short-time
 reference. As in the tutorial book described all objects deriving from
 osg::Referenced should be used with ref_ptr for proper use.
 But even in the book and in some tutorials there are many uses of the plain
 c++ pointer without the reference use of ref_ptr.
 There is where I have one question, if I develop in VisualStudio for
 instance and write some code like:

 osg::Geode * g = new osg::Geode;
 ...
 viewer.setSceneData(g);

 Doesn't I have a ref count of 2 for g? Whild would result in a leak since I
 never delete the g pointer manually?

 If this above is true and the programm is running as a childprocess of my
 IDE (since I have debugging and stacktracing and so on), don't I create some
 leaking beyond the lifetime of the programm? I am not quite sure if the
 memory is cleaned after finishing the programm or the whole IDE.

 Thanks
 Sam
 ___
 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::State::captureCurrentState does not capture texture modes, texture attributes and uniforms

2008-04-11 Thread Maciej Krol
Hi all,

I am writing converter from fixed pipeline to glsl. I need to know exact
state set of my drawables. For this purpose I have prepared node visitor
that uses osg::State to accumulate node states. The visitor at the drawable
uses osg::State::captureCurrentState to fetch accumulated state. The problem
is that texture modes, texture attributes and uniforms are not copied. How
can I access them? All required members of osg::State are protected and
there is a lack of accessor methods.

Best Regards,
 Maciej Krol
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] osg::State::captureCurrentState does not capture texture modes, texture attributes and uniforms

2008-04-11 Thread Maciej Krol
Hi Robert,

Thanks for the tip, I did not know StateSet::merge method. I will try this
out.

Best Regards,
 Maciej Krol

2008/4/11, Robert Osfield [EMAIL PROTECTED]:

 Hi Maciej,

 osg::State is probably not the best way to accumulate state for general
 CPU computation work as its totally geared around the rendering side.

 What you are better off doing is creating a stack of osg::StateSet that
 you push/pop as you traverse the scene graph.  When you encounter
 nodes/drawables that have a StateSet then clone the topmost StateSet of the
 stack and then do a StateSet::merge with the new one.

 I haven't actually implemented this myself before but this is at least how
 I'd go about it.

 Robert.

 On Fri, Apr 11, 2008 at 10:22 AM, Maciej Krol [EMAIL PROTECTED] wrote:

  Hi all,
 
  I am writing converter from fixed pipeline to glsl. I need to know exact
  state set of my drawables. For this purpose I have prepared node visitor
  that uses osg::State to accumulate node states. The visitor at the drawable
  uses osg::State::captureCurrentState to fetch accumulated state. The problem
  is that texture modes, texture attributes and uniforms are not copied. How
  can I access them? All required members of osg::State are protected and
  there is a lack of accessor methods.
 
  Best Regards,
   Maciej Krol
 
  ___
  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] Testing of OSG SVN in prep for 2.3.8 dev release

2008-04-11 Thread Maciej Krol
Hi Robert,

I have a problem with compiling curl plugin under WinXP VS2005 SP1. I am
using latest revision of 3rdParty from Mike Weiblen.
The problem is that 3rdParty directory contains static curlib, while osg
expects dynamic one.
To link with static library we need following changes (probably optional in
cmake):
- #define CURL_STATICLIB (see curl.h).
- add dependencies: ws2_32.lib winmm.lib

I think it should be incorporated into cmake files. I do not have any
experience with cmake language and so far I have tested it by manual
tweaking of VS project files.

Best Regards,
 Maciej Krol

2008/4/11, Robert Osfield [EMAIL PROTECTED]:

 Hi All,

 I'm back from my trip, and through today have caught up with the pending
 submissions, so we should be pretty up to date now and ready for the next
 dev release.  Before I tag the beast could users do an svn update and let me
 know how the build and run goes.

 Thanks,
 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] Rewrite of DatabasePager::removeExpiredSubgraphs(double)

2008-03-29 Thread Maciej Krol
Hi Robert,

Great improvement! Memory usage dropped almost 6 fold for our paged scenes,
from oscillating around 350MB to rock solid 60MB (WinXP).

Many thanks,
 Maciej

2008/3/28, Robert Osfield [EMAIL PROTECTED]:

 Hi All,

 Testing that I've been carrying out on some new big terrain databases
 has shown some real weaknesses in the DatabasePager ability to load
 balance - with memory footprint growing significantly when the camera
 moves fast over wide areas of high res data.  Memory usage was growing
 to over 4GB and blowing our test computers, hardly something that is
 desired for a database paging system that is supposed to maintain a
 modest memory footprint.

 After much investigation the cause of the rather unconstrained memory
 usage has been traced to the slow speed that the DatabasePager was
 expiring (removing) no longer visible subgraphs - subgraphs were
 correctly ear marked for removal but idsyncrosies in the threading and
 original DatabasePager::removeExpiredSubgraphs(..) method meant that
 it would take many frames to finally let go expired subgraphs.  It in
 fact was taking long enough that new data was coming in at a far
 faster rate than it was been removed at hence the dramatic growth in
 memory footprint.

 The solution has been to rewrite
 theDatabasePager::removeExpiredSubgraphs(..) method that is
 responsible for expiring subgraph and setting them aside for deletion.
   I've now got this new implementation working and sees a memory
 footprint halved which not affecting the visual quality on screen.
 Performance is now much more stable and crashes due to excessive
 memory consumption are gone on my test machine.  With this rewrite a
 couple member variables and their associated set/getters are no longer
 required, and rather leave them around for potential confusion I've
 removed them completely so an svn update if you get an compile error
 just remove the below methods and recompile.

 -/** Set the maximum number of PagedLOD child to remove per frame
 */
 -void setMaximumNumOfRemovedChildPagedLODs(unsigned int
 number) { _maximumNumOfRemovedChildPagedLODs = number; }
 -
 -/** Get the maximum number of PagedLOD child to remove per frame
 */
 -unsigned int getMaximumNumOfRemovedChildPagedLODs() const {
 return _maximumNumOfRemovedChildPagedLODs; }
 -
 -/** Set the minimum number of inactive PagedLOD child to keep */
 -void setMinimumNumOfInactivePagedLODs(unsigned int number) {
 _minimumNumOfInactivePagedLODs = number; }
 -
 -/** Get the minimum number of inactive PagedLOD child to keep */
 -unsigned int getMinimumNumOfInactivePagedLODs() const {
 return _minimumNumOfInactivePagedLODs; }

 I would like to improve this method further still as I've already come
 up with a better load balancing algorithm to implement in this method,
 however, it'll take a while longer to implement, so rather than wait
 for this polished implementation I'm checking in what is working
 effectively, albeit not perfect it is far better than what was there
 before.

 There are other aspects of the DatabasePager that need attention too,
 such as the high cost of DatabasePager::requestNodeFile() method
 during cull traversal when many file requested are queued up.  This is
 something that has been raised on the list before by others, so it's a
 bit of common theme when we really start to push the size of paged
 databases we are dealing with.   I will be spending more time on this
 code over the coming month, so feel free to chip in with your own
 experiences.

 Cheers,
 Robert.
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] osgPPU-0.1 developer release

2008-03-28 Thread Maciej Krol
Hi Morne,

I have similar problem when I am behind proxy, the svn protocol is being
blocked. When subversion is available through http I do not have any
problems.

Art, would it be a problem to change the protocol from svn to http(s). It
would solve access problems for corporate users which are usually behind
proxy.

Regards,
 Maciej

2008/3/27, Morné Pistorius [EMAIL PROTECTED]:

 Hi Art,

 Could you provide a downloadable zip file or something?  When I try to
 check out the SVN version, I get this error:

 Error: Can't connect to host 'projects.tevs.eu': No connection could
 be made because the target machine actively refused it.

 Cheers,
 Morne



 On Thu, Mar 27, 2008 at 1:56 PM, Art Tevs [EMAIL PROTECTED] wrote:
  Hi folks,
 
   I finally found some time and now there is a first
   developer release of osgPPU Nodekit (ok not directly
   a node kit, because not derived from a node, but this
   will follow ;-).
   Here is the homepage of the project:
   http://projects.tevs.eu/osgppu/wiki
 
   There are couple of example applications showing it in
   action. I will be very appreciated if somebody of you
   would contribute to this project with new
   ideas/critics/bug-huntings/features/...
 
 
   Best regards,
   Art
 
 
 
 
 
 
Lesen Sie Ihre E-Mails jetzt einfach von unterwegs.
   www.yahoo.de/go
   ___
   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