Thanks Robert, fix looks good.
The README.txt is still somewhat confusing so I have updated it
accordingly, see attached file.
Regards,
/Per
On 19 November 2014 18:47, Robert Osfield wrote:
> Hi Per et. al,
>
> I have merged something very similar to Per's/simgear's script, and now the
> cmake
Hi Per et. al,
I have merged something very similar to Per's/simgear's script, and now the
cmake . defaults to building Release I have also removed the old configure
script file that provided a simply means for setting the release type, as
this isn't required any more - standard cmake invocation w
I'll have a look tomorrow morning as soon as I get back to work...
Le mer. 19 nov. 2014 à 18:26, Alberto Luaces a écrit :
> Chris Hanson writes:
>
> > Hmm. This is not the default branch for GitHub? Shouldn't it be, then?
>
> Up to some weeks ago, SVN trunk was tracked by github's master. That i
So, what do you think The Right Thing to do would be? I'm not GitHub savvy
enough to have a valid opinion.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Chris Hanson writes:
> Hmm. This is not the default branch for GitHub? Shouldn't it be, then?
Up to some weeks ago, SVN trunk was tracked by github's master. That is
the reason why when I updated my remotes, everything said it was "up to
date".
--
Alberto
_
Hmm. This is not the default branch for GitHub? Shouldn't it be, then?
On Wed, Nov 19, 2014 at 10:02 AM, Alberto Luaces wrote:
> The development seems to have moved to github's 3.2 branch:
>
> https://github.com/openscenegraph/osg/tree/OpenSceneGraph-3.2
>
> --
> Alberto
>
>
The development seems to have moved to github's 3.2 branch:
https://github.com/openscenegraph/osg/tree/OpenSceneGraph-3.2
--
Alberto
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-o
Hi,
The website uses a github widget to show last commits. So the information
on the web is the same as on github.
El miércoles, 19 de noviembre de 2014, Chris Hanson
escribió:
>
> I see that too. I assumed that WAS the latest commit since it's the
> latest commit listed on the OSG web page fee
I see that too. I assumed that WAS the latest commit since it's the latest
commit listed on the OSG web page feed:
http://www.openscenegraph.com/
- Added experimental osgTerrain::ShaderTerrain TerrainTechnique to
osgterrain example to flesh out new shader based displacement mapping
appr
Chris Hanson writes:
>> On Wed, Nov 19, 2014 at 8:45 AM, Alberto Luaces wrote:
>>
>> It seems that the repo at github is not being updated for several
>> weeks.
>>
>> Mathieu, can you take a look at it, please?
>>
>> Thank you!
>
> I pulled from it last night and I though
I pulled from it last night and I thought the last commit matched Robert's
last SVN commit.
On Wed, Nov 19, 2014 at 8:45 AM, Alberto Luaces wrote:
> It seems that the repo at github is not being updated for several weeks.
>
> Mathieu, can you take a look at it, please?
>
> Thank you!
>
> --
> Al
Hi Bjorn,
Did you come up with a sensible solution for this? If so could you post me
your changes so I can review/merge them.
Thanks,
Robert.
On 20 July 2014 18:43, Björn Blissing wrote:
> Hi Robert,
>
> I tried both options and they both seem to work. Although I guess some
> deeper benchmark
Ah! Infamously ambiguous as always.
I meant that I have an osg::projection as the "background" for my HUD. I
managed to solve it about 2 minutes before you posted it.
Like I mentioned I had two models playing animations on the HUD which is just a
green 4 point rectangle geode I create with
Hi Chris,
On 19 November 2014 15:17, Chris Hidden wrote:
> No worries on the books then. I was more thinking like a good 3D graphics
> programming book to get my head around the concepts of things. Since I
> still struggle in understanding some of the basics I believe.
>
I'll defer to others
It seems that the repo at github is not being updated for several weeks.
Mathieu, can you take a look at it, please?
Thank you!
--
Alberto
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-
No worries on the books then. I was more thinking like a good 3D graphics
programming book to get my head around the concepts of things. Since I still
struggle in understanding some of the basics I believe.
I have one last question now regarding my HUD. I just moved the 3D models of
the HUD
Hi Chris,
On 19 November 2014 13:43, Chris Hidden wrote:
> Thanks again Robert.
>
> I believe the hudCamera->setGraphicsContext(windows[0]); approach is
> exactly as its written in the osghud example?
>
I just checked and it is :-)
Just shows I can't remember everything off the top of my head
Thanks again Robert.
I believe the hudCamera->setGraphicsContext(windows[0]); approach is exactly
as its written in the osghud example?
But I have fixed it now. As you said, once I applied both a color and depth
clear to the slave camera with pre render and only a depth buffer for the main
c
On 19 November 2014 10:57, Chris Hidden wrote:
> Ok, I think I understand what was going on. I am now using
>
> osgViewer::Viewer::Windows windows;
> viwer->getWindows(windows);
>
> if (windows.empty()) return 1;
>
> hudCam->setGraphicsContext(windows[0]);
>
> However, if
Hi Chris,
You code is creating two graphics windows one for each camera, this of
course will result in the camera not appearing overlapping on the same
window.
Have a look at the osghud example - the context is shared. For the main
camera you should *just* clear the depth buffer, in your code yo
Thanks Robert.
I tried not setting any clear mask on the slave camera and making sure the
depth clear was on my main camera. I haven't got the desired effect yet.
My main camera has these settings:
Camera mainCam = new Camera(*(view->getCamera()));
mainCam->setGraphicsContext(osg::GraphicsC
A followup with some observations I made:
When one sets the supportsResize property of the graphics context to false,
Windows lets one create windows that extend beyond the screen dimensions.
But as soon as resizing is permitted, Windows Vista and above enforces
sizing restrictions (that the previ
Hi Chris,
The key to managing multiple Camera's that overlay each other is to decide
how you want to mange the depth buffer for each of the cameras. For the
setup in your description - a Camera to render the background, then a main
camera to render the main scene I'd use a PRE_RENDER for the back
Hi everyone.
I have a HUD in my application that I want to contain 3d Models with
animations. I have taken a look at the osghud example in the build and have a
HUD working with a slave camera.
I want the HUD to be behind my main scene object though ( opposite of most HUD
implementations ).
Thanks James, fix merged and submitted to svn/trunk.
On 15 November 2014 15:17, James Turner wrote:
>
> On 14 Nov 2014, at 10:49, James Turner wrote:
>
> I realise my original report was a little lacking in info, I am working to
> get everything compiled with additional debug / logging so I can
Hi Robert,
On 18 November 2014 18:17, Robert Graf wrote:
> Hi Robert, thanks for checking in. Setting OSG_WINDOWING_SYSTEM to "Cocoa"
> in CMake resolves the linker issue.
>
> Currently, the CMake build configuration defaults OSG_WINDOWING_SYSTEM to
> "Carbon" when building on OSX, but when exa
26 matches
Mail list logo
