[osg-users] problem of rendering overlaped models.

hi friends: i have 2 models to render, some part of which are overlaped . so the result is some kind of weird. how can i resolve this probem? do i need to split the model and align them? or set different render details for the 2 models? Shawl__

Re: [osg-users] osgManipulator::TrackballDragger geometry of size of bounding sphere

Thanks for answering Robert. I understand your position but I have already taken a look to the source code. The problem is that I very new to OSG & OpenGL programming, so it is difficult to me to understand it. Nevertheless, I can see on line 127 of TrackballDragger.cpp, this line of code: Cod

Re: [osg-users] Cheaper way to implement rendering-to-texture and post-processing pipeline?

Hi Paul, On 15 February 2013 04:09, Paul Martz wrote: > Now that I give this some more thought, the concept of post-processing is > inherently non-spatial, so it really doesn't belong in a scene graph at all. > Repeatedly "culling" entities that we know will always be rendered is > redundant at b

Re: [osg-users] How to use texture atlases in OSG?

HI Michael, With a well constrained problem like tile textures I wouldn't bother with using the TextureAtlasBuilder, it's crude compared to what a human can create as the human knows all the constraints up front and has a brain that can understand the usage model and the in's and outs of optimizin

Re: [osg-users] Cheaper way to implement rendering-to-texture and post-processing pipeline?

Hi, In my present implementation in the osgRecipes project, I create a list of pre-render cameras internally as post processing passes, instead of explicitly in the scene graph. So on the user level they may simply write: EffectCompositor* effect = new EffectCompositor; effect->loadFromEf

Re: [osg-users] Cheaper way to implement rendering-to-texture and post-processing pipeline?

Hi, > the concept of post-processing is inherently non-spatial, so it really > doesn't belong in a scene graph at all => this is why I think we should be able to execute a render pass on an arbitrary camera : the subgraph of this camera may not have a spatial organization, but a process-logi