Hi Sebastian,
Yes, I have to admit that my question was not clear enough. Actually I meant
using C++11 in osg-based apps. The reason I asked is that I would like to write
a high-level rendering engine based on osg (to be distributed to many users)
and I was not sure if I should directly use
Thanks Robert, I fixed the problem on my viewer side getting the camera from
the view.
Regards
Gianni
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=57385#57385
___
osg-users mailing list
Am 22.11.2013 10:23, schrieb deniz diktas:
Hi Sebastian,
Yes, I have to admit that my question was not clear enough. Actually I meant
using C++11 in osg-based apps. The reason I asked is that I would like to write
a high-level rendering engine based on osg (to be distributed to many users)
Hi Deniz
I am currently using OSG 3.2 in a source code using several C++11 features and
everything works as expected. I am using Visual Studio 2012.
OSG is very object oriented, while C++11 is more towards generic programming,
so sometimes you need to adapt concepts.
-Original
Hi Robert, do you have any idea regarding the strange effect I have with
osgWidgets? I try to repeat my issue.
You can see my viewer code I posted above (now fixed getting the camera of the
view). The viewer inherits from osgQt::GLWidget and osgViewer::CompositeViewer
and I set the camera
Hi Gianni,
I'll have to defer to Jeremy Moles on osgWidget support.
Robert.
On 22 November 2013 10:41, Gianni Ambrosio ga...@vi-grade.com wrote:
Hi Robert, do you have any idea regarding the strange effect I have with
osgWidgets? I try to repeat my issue.
You can see my viewer code I
Gianni Ambrosio writes:
Now, if I run my application without resizing the viewer widget and I
insert an osgWidget::Window to the osgWidget::WindowManager I can see
it stretched to a small size. Then I resize the viewer interactively,
the code falls into the handled resizeEvent and the
Alberto Luaces wrote:
Initially osgWidgets relies on the size you specify when you create the
WindowManager, and it can be different than the actual size of your
rendering context. OSG doesn't send a RESIZE event at window creation
time, so you have to check this for yourself.
Alberto,
Hi Robert,
Thank you for your answer. Unfortunately, I cannot share the model ...
However, I can share the code.
Here it is:
// Building a osgUtil::PolytopeIntersector from a CONCAVE planar polygon
/* 1) split the concave polygon in its convex rings */
/* 2) iterate over each
Gianni Ambrosio writes:
Alberto Luaces wrote:
Initially osgWidgets relies on the size you specify when you create the
WindowManager, and it can be different than the actual size of your
rendering context. OSG doesn't send a RESIZE event at window creation
time, so you have to check this for
Hi Olivier,
It sounds like the next thing to investigate would be the size of the
bounding sphere that it's testing against, perhaps there is an error in the
bounding sphere settings that is resulting in the traversal being culled
prematurely.
Robert.
On 22 November 2013 14:03, Olivier
Hi Robert-
I agree the osgDB::readRef*File() functions are safe. I was only noting that
the osgDB::readRef*File() functions that return raw pointers are used in more
than just Input.cpp and the deprecated wrappers as you'd mentioned.
As for whether using the take methods invalidate the
Hi Baker,
On 22 November 2013 15:55, Bradley Baker Searles bakersear...@gmail.comwrote:
I agree the osgDB::readRef*File() functions are safe. I was only noting
that the osgDB::readRef*File() functions that return raw pointers are used
in more than just Input.cpp and the deprecated wrappers as
Thank you guys,
This is helpful, I can see it is best to stick to vs2010 and use boost for
missing c++11 features, which I have been doing in my regular work anyway. Good
to see we are on the same page here.
Any other opinions or suggestions are welcome.
-deniz
--
Read this
Hi guys,
It's OT but I do like to ask your help with building the OSG on Windows
8. I was wondering if anyone can give me a hand with building the OSG on
Windows 8. I have build OSG numerous times on any other platform but now
I am trying to build the OSG (3.1.1 but that does not matter) on
Hi,
Im compiling various projects including OSG on windows 8 with VS 2012 and
VS2013 - I have no problem with such an error. Is your computer integrated into
a AD domain?
Cheers,
Torben
--
Read this topic online here:
Hi,
No, I am using a local account. It's a fresh installation. Did you
change any settings for your account?
cheers
Raymond
On 11/22/2013 10:42 PM, Torben Dannhauer wrote:
Hi,
Im compiling various projects including OSG on windows 8 with VS 2012 and
VS2013 - I have no problem with such
Hi,
I'm currently working on the Windows 3rdParty precompiled dependency package
for Visual Studio 2013.
During my test compilations with OSG trunk I discovered that Microsoft droppen
MB support for MFC in VS2013. This is used by OSG's MFCViewer example.
I tried to switch the project ot
On 22 November 2013 21:52, Torben Dannhauer tor...@dannhauer.info wrote:
Or should we disable the example for MSVC 2013
Or get rid of it completely? Is MFC not deprecated now?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
Hello dear OSG-community,
Sorry again for my long absence:
PhD finished: check
Married: check
- now it's time to dive into OSG again :)
As Visual Studio 2012 's C++ compiler is even after Update 4 quite buggy, I
switchted to VS2013 asap, since there are (at least) my annoying VC bugs fixed
by
Hi, Robert,
it is not deprecated per se,
but as stated here:
http://blogs.msdn.com/b/vcblog/archive/2013/07/08/mfc-support-for-mbcs-deprecated-in-visual-studio-2013.aspx
,
they had to maintain/install/deploy too many flavors of MFC.
To optimize it they decided to put multibyte support in a
Deniz,
What do you mean?
I've been using Visual Studio 2010, which has some major parts for C++11
integrated with OSG.
Lambdas, move etc. are just working fine.
I would not recommend to move the OSG core to c++11 too soon, as right
now there is a great variety of compiler targets for OSG. And
Hi Baker,
On 21 November 2013 20:57, Bradley Baker Searles bakersear...@gmail.comwrote:
I am not sure I understand your last paragraph. I believe every
osgDB::read*File() function would need to be changed to not use the take
functions. They all pose a multi-threaded risk with the object
23 matches
Mail list logo
