Hi,
I have a stupid question. What is a bounding box and how to use it?
Thank you!
Cheers,
Julie
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65003#65003
___
osg-users mailing list
osg-users@list
cbuchner1 wrote:
> Trying to build the current osgoculus master branch against Oculus SDK
> 0.7.0.0 using OSG 3.2.1
>
>
> the following code from oculusdevice.cpp is making trouble. For OSG 3.2 the
> variable "ctx" is undefined.
>
> void OculusTextureBuffer::setRenderSurface(const osg::State
The presentation I did is on-line at
http://www.nist.gov/itl/math/hpcvg/pubs.cfm
I added a narration, so its now a 9 minute video.
-Steve Satterfield
st...@nist.gov
On Fri, 14 Aug 2015, John Richardson wrote:
Hello,
Thanks to Robert for his "future of OSG" slides.
Thanks to David Gle
I also recommend using the Triton height map support to make the shorelines
look better. It will fade out the ocean geometry as the bathymetry slopes
up towards sea level.
Logarithmic depth buffer is handy for various Triton use cases. If you go
that route, remember to also reduce your near/far ra
Hi Mike,
On 2 September 2015 at 16:09, Mike Greene wrote:
> Having problems with Z-fighting when using a very large terrain database
> and mixing it with Triton ocean - seeing lots of z-fighting along the coast
> line where the water and the terrain depths are nearly the same. I can
> alleviate
Hi Mike,
http://sundog-soft.com/sds/2015/06/using-an-opengl-logarithmic-depth-buffer-in-silverlining-and-triton/
It will help alot with high z-ranges, but I had trouble inverting the
function in my deferred pipeline, so I cannot use it right now.
Initial tests however yielded great results.
H
Hi Mike,
have you tried using of height map with Triton? I am aware of the same
issue and considering logarithmic depth buffer ... Suggested by Frank
Nick
On Wed, Sep 2, 2015 at 5:09 PM, Mike Greene wrote:
> Having problems with Z-fighting when using a very large terrain database
> and mixing
Having problems with Z-fighting when using a very large terrain database and
mixing it with Triton ocean - seeing lots of z-fighting along the coast line
where the water and the terrain depths are nearly the same. I can alleviate the
problem by reducing the near/far clip boundaries, but this is
Hi James,
sorry for the late reply!
Please, feel free to review and merge my code, let me know if you need
clarifications.
Ricky
On Mon, Aug 24, 2015 at 4:03 PM, James Turner wrote:
>
> On 17 Aug 2015, at 17:33, Riccardo Corsi
> wrote:
>
>
> Thanks Ricky.
>
> From my point of view the most de
A followup: inserting the following line into both #else branches fixes it
const unsigned int ctx = state.getContextID();
2015-09-02 11:06 GMT+02:00 Christian Buchner :
>
> Trying to build the current osgoculus master branch against Oculus SDK
> 0.7.0.0 using OSG 3.2.1
>
> the following code fr
Trying to build the current osgoculus master branch against Oculus SDK
0.7.0.0 using OSG 3.2.1
the following code from oculusdevice.cpp is making trouble. For OSG 3.2
the variable "ctx" is undefined.
void OculusTextureBuffer::setRenderSurface(const osg::State& state)
{
#if(OSG_VERSION_GREATER_OR_
Dear all,
I need to do shadows in an GL 3.2 / glsl 1.5 environment.
I was using osgShadow with LightSpacePerspectiveShadowMapCB technique
before moving to 3.2/1.5.
I tried to track down the necessary actions and I think I have to solve
3 items:
1) Assigning new shaders to the technique (Standa
Thanks guys. Personally I third your opinions, but wanted to bring it up.
cheers
Mattias
On Wed, Sep 2, 2015 at 9:56 AM, Sebastian Messerschmidt
wrote:
> Hi Matthias,
>
> I second Robert's opinion. Passing a zero-length vector simply causes in
> invalid results to be calculated.
> My vote would b
Hi Matthias,
I second Robert's opinion. Passing a zero-length vector simply causes in
invalid results to be calculated.
My vote would be towards using an assert, so the user is noticed in
debug builds about the potentially wrong results.
Thats what some other libraries do to hint invalid parame
Hi Mattias,
On 2 September 2015 at 08:24, Mattias Helsing wrote:
> I guess it's to old performance vs user-friendliness problem, and
> that's why I wanted to bring it up here before submitting anything.
>
> What do you think?
>
For code that used in inner loops I generally prefer to avoid extr
Hi
Our team chased down a bug where we passed an invalid rotation vector to:
void osg::Quat::makeRotate(const osg::Vec3d& from, const osg::Vec3d& to)
we passed an all zeroes Vec3d in the from parameter. This is then used
to normalize the vector, which causes INF values and lots of bad
things fur
Hi Thomas,
Only see the osgviewer.zip.002, was there an .001.
I'm a bit perplexed by needing to zip a stack trace up. I work predominatly
under Linux so Windows specific files are far less useful than straight
text outputs for things like stack traces.
Aside for the stack trace issues, one thing
17 matches
Mail list logo