Re: [osg-users] Conan C++ dependency manager

Hi, Great to see integrate osg to conan. Users could use osg from conan without having to rebuild it. ... Thank you! Cheers, Ben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72721#72721 ___

Re: [osg-users] How to get Center Parameter of CameraManipulator

Hi, Why not use getHomePosition(), which is a member of CameraManipulator ... Thank you! Cheers, Ben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72720#72720 ___ osg-users mailing list

[osg-users] PIXEL_SIZE_ON_SCREEN And RangeList of osgb file

Hi, my osgb's "head" is like this: osg::PagedLOD { UniqueID 1 CenterMode USER_DEFINED_CENTER UserCenter -1619.41 -187.445 1047.71 40.4089 RangeMode PIXEL_SIZE_ON_SCREEN RangeList 2 { 0 1293.08 1293.08 1e+030 } DatabasePath TRUE "D:\\Tile_050_050/" RangeDataList 2 {

Re: [osg-users] Conan C++ dependency manager

@korner I rethink of your idea to merge recipe into master but I think a dedicated repo for per release conan recipes would be best for package maintenance (one recipe involving multiple different arch packages, one per release allows the number of potential differents packages to be

Re: [osg-users] Conan C++ dependency manager

I think integrating Conan and OSG is a fantastic idea, and one I've wanted to do but haven't had time in the past. On Wed, Jan 10, 2018 at 8:50 AM, Julien Valentin wrote: > Hi korner > > as the repo title says it's just an experiment > I shared it but there are

Re: [osg-users] Slave camera lighting with disabled main camera

No worries, thank you for looking into it anyway. :) To be honest, I don't think that "fixing" this behavior within OSG is worth it. The code additions to ViewerBase::renderingTraversals() would be duplicated from Renderer and SceneView, and would only benefit fringe cases where the user wants

[osg-users] OpenThreads Doxygen documentation

The OpenSceneGraph 3.4.0 documentation will build (after adding EXTENSION_MAPPING = "no_extension=C++" to the doxyfile). However, the OpenThreads documentation will not build even with that additional line. Errors on Windows 7 include the following along with numerous additional ones of the

Re: [osg-users] Slave camera lighting with disabled main camera

Hi Ravi, Oh well. I've removed the LightingMode changes, there is a little clean up in there so I've merged this with master. FYI, LightingMode is really just there for convince and backwards compatibility back to the 1.0/2,0 days of the OSG. These days I'd write lighting management all myself

Re: [osg-users] Slave camera lighting with disabled main camera

robertosfield wrote: > Ops, don't send modifications without compiling them first... > > The View::LightingMode and SceneView::LightingMode aren't compatible > enum's so can't be passed as is. I've spotted a better way of doing > this update, putting into the Renderer::updateSceneView() method

Re: [osg-users] Conan C++ dependency manager

Hi korner as the repo title says it's just an experiment I shared it but there are problems..just try it if you have the time to experiment these. As an example problem : I passed the night wandering why it didn't copy all headers but haven't found why cheers kornerr wrote: > Hi. > May be

Re: [osg-users] Slave camera lighting with disabled main camera

Ops, don't send modifications without compiling them first... The View::LightingMode and SceneView::LightingMode aren't compatible enum's so can't be passed as is. I've spotted a better way of doing this update, putting into the Renderer::updateSceneView() method along with the setting of the

Re: [osg-users] Slave camera lighting with disabled main camera

HI Ravi, On 10 January 2018 at 14:53, Ravi Mathur wrote: > I just checked, and the same behavior & solution exists on master. Looking at the internal setup of the rendering backend I think the reason for the behavior is that the Renderer implement found in

Re: [osg-users] Slave camera lighting with disabled main camera

ravidavi wrote: > > robertosfield wrote: > > HI Ravi, > > > > I haven't yet looked deeply into the issue as I'm still in post > > holiday catch up mode. What version of the OSG are you using? > > > > Robert. > > > > > I'm on the OpenSceneGraph-3.5.6 tag. I just checked, and the same

Re: [osg-users] Slave camera lighting with disabled main camera

robertosfield wrote: > HI Ravi, > > I haven't yet looked deeply into the issue as I'm still in post > holiday catch up mode. What version of the OSG are you using? > > Robert. > I'm on the OpenSceneGraph-3.5.6 tag. -- Read this topic online here:

Re: [osg-users] Free camera manipulator

Okay. Thank you! Cheers, Kazim -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72707#72707 ___ osg-users mailing list osg-users@lists.openscenegraph.org

Re: [osg-users] [vpb] support for WildCard

Thanks Robert. -- Thank You, Saket -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72706#72706 ___ osg-users mailing list osg-users@lists.openscenegraph.org

Re: [osg-users] Conan C++ dependency manager

Hi. May be introduce some sort of subdirectory (like osg_src/packaging/conan) into the main OSG source tree as a pull request? Having separate repository doesn't seem correct. On 10 January 2018 at 02:13, Julien Valentin wrote: > > mp3butcher wrote: >> Hi all >> I

Re: [osg-users] [vpb] support for WildCard

Hi Saket, It's the OS's command line parser that it expanding the wild card, this will expand the command line with a list of files, only the first of which will be prefixed by a -d. I don't know of other help tools that might provide the functionality you are after. osgdem is just a small

[osg-users] [vpb] support for WildCard

Hi, During my initial understanding for the command line arguments, I observed that wildcard do not work in path for terrain [-d] or texture [-t] files. i.e. such arguments do not work -d /path/*N15*.tiff If i use wildcard, only the first file in listing is taken up. Can someone suggest an

Re: [osg-users] Slave camera lighting with disabled main camera

HI Ravi, > If Robert or any of the other experienced folks on here think that I'm > mistaken on this, or have other more elegant solutions, please let me know. > Otherwise I'll consider the matter closed. I haven't yet looked deeply into the issue as I'm still in post holiday catch up mode.