Hi Robert,
Another minor observation is that intersections no longer seem to work on
osgText. You can see this in the osgpick example when you click on any of the
text.
Cheers,
Jamie
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=70722#70722
Hi Jamie,
Thanks for the testing, fixes and test model.
I have just tried your model on my Linux/NVidia system and see the
same black text when I enable stats. While it's not good news to see
a problem it's a relief to be able to reproduce it.
Robert.
On 6 April 2017 at 20:48, jamie robertson
Hi,
I just tested it with windows 10 / VS2013. I had to make a couple of minor
changes to the osgcluster and osgbindlesstext in order to get those examples to
compile. I've posted the modified files in submissions.
It works ok for the most part but I've noticed a few models (which used to work
On 5 April 2017 at 21:38, Konstantin wrote:
> I've sent upgraded osgtext3D example to osgsubmissions.
Thanks, the change nicely reproduce the bug. I will work to resolve
this bug before I tag 3..5.6. I have other work to do this week so
might not get to it right away.
Hi, Robert!
I've sent upgraded osgtext3D example to osgsubmissions.
Best wishes!
KOS
2017-04-05 18:12 GMT+03:00 Robert Osfield :
> Hi KOS,
>
> On 5 April 2017 at 15:41, Konstantin wrote:
> > First... Thanks :)
> > I've compiled 3.5.6 with GL3
Hello, Robert!
First... Thanks :)
I've compiled 3.5.6 with GL3 core on Macmini (OpenGL 3.3) with no problems.
BUT.
I have application based on OpenSceneGraph 3.4.0 (built with GL3 profile)
and it works well on Mac (in OpenGL 2.1 compatibility context)
When I've switched to 3.5.6 (GL3 core)
master does not compile on mys2 anymore due to recent changes in osgcluster
example.
Error is :
D:/M/mingw-w64-openscenegraph-git/src/OpenSceneGraph/examples/osgcluster/broadcaster.cpp:139:17:
error: 'ifr' was not declared in this scope
strcpy( ifr.ifr_name, _ifr_name.c_str());
Hi,
and the callstack:
Code:
osg147-osgd.dll!osg::MixinVector::front() Line 139
C++
osg147-osgTextd.dll!osgText::Text::accept(osg::PrimitiveFunctor & pf)
Line 1276 C++
osg147-osgUtild.dll!osgUtil::RenderBin::getStats(osgUtil::Statistics &
stats) Line 586 C++
Hi
I have sometimes crashes on stats (osgText) with Windows:
Expression: vector iterator not dereferencable at
Code:
void Text::accept(osg::PrimitiveFunctor& pf) const
{
pf.setVertexArray(_coords->size(), &(_coords->front()));
for(TextureGlyphQuadMap::const_iterator
I went ahead and just commented out some openthread logging.
See https://github.com/openscenegraph/OpenSceneGraph/pull/238
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=70614#70614
___
osg-users
Hi Robert,
I am really sorry to insist so heavily, but please take a quick look at
https://github.com/openscenegraph/OpenSceneGraph/issues/209.
I am ready to make the changes, test them and submit a PR but need some
directions.
OpenThread has been outputting some unwanted debugging information
Latest master tested ok on msys2.
All that remains is some OpenThread related spam on the console :
$ ./build/librepilot-gcs_release/bin/librepilot-gcs.exe -reset
setProcessorAffinity() : affinity.activeCPUs.size()=1, numprocessors=4
setting CPU : 0
affinityMask = 1
setProcessorAffinity() :
Thannks Remo, PR with fix now checked into OSG master. Crossing
fingers and toes that we're good to go now.
On 29 March 2017 at 14:14, Robert Osfield wrote:
> Hi Remo,
>
> Could you try and fix this compiler specific issue as I don't have the
> your compiler/build
Hi Remo,
Could you try and fix this compiler specific issue as I don't have the
your compiler/build combination to test against. I presume the code
is fine as others aren't reported problems even with VisualStudio, so
I suspect it must be a specific compiler or build combination issue
that
Hi Robert
I use VS2013. It could be that:
http://stackoverflow.com/questions/26959188/fatal-error-c1017-invalid-integer-constant-expression-when-using-if-false
Cheers,
Remo
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=70603#70603
Hi Robert,
robertosfield wrote:
> Hi Stuart,
>
> On 28 March 2017 at 19:46, Stuart Mentzer <> wrote:
>
> > osgWrappers/serializers/osgVolume/MultipassTechnique.cpp was added since my
> > prior (successful) build with VC++ 2015 (at rev 6308b4). VC++ needs the
> > definition of osg::Texture2D
Hi Robert
Thanks. I've another. On Win64 I have the following compile error:
Code:
\src\osg\State.cpp(99): fatal error C1017: invalid integer constant expression
See at:
https://github.com/openscenegraph/OpenSceneGraph/blob/master/src/osg/State.cpp#L99
I've build it with the defaults and
Hi Remo,
On 29 March 2017 at 11:32, Remo Eichenberger wrote:
> The shaders on StateSet.cpp and osgvertexattributes doesn't compile on MacOSX
> Core Profile / GL3:
StateSet.cpp is an easy fix because there are already separate shaders
for GL2 and GL3, I've now checked in
Hi
The shaders on StateSet.cpp and osgvertexattributes doesn't compile on MacOSX
Core Profile / GL3:
texture2D() should be texture()
Cheers,
Remo
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=70598#70598
I have now checked in a fix for the osg::ShadeDrawable bug with the
windings being reversed on some shapes.
There is still time for testing folks, let me know if things are
working fine or not. If things looks good I'll tag the dev release
this afternoon.
Thanks for you assistance,
Robert.
Hi Stuart,
On 28 March 2017 at 19:46, Stuart Mentzer wrote:
> osgWrappers/serializers/osgVolume/MultipassTechnique.cpp was added since my
> prior (successful) build with VC++ 2015 (at rev 6308b4). VC++ needs the
> definition of osg::Texture2D (and other types used in members)
robertosfield wrote:
> Hi Stuart,
>
> I don't recall resent changes to the files mentioned in your compiler
> output, this makes a bit more difficult to point point what might have
> caused this problem.
>
> When was the last time you build OSG master? Was it with the same
> OS/Compiler set?
On 28 March 2017 at 17:46, Li Chi wrote:
> Just as you said, I did a test for changing DrawElementsUShort to
> DrawElementsUInt in function 'void BuildShapeGeometryVisitor::End()',
> everything looks good now.
I have introduced what is done in osgTerrain into
Hi Robert,
Just as you said, I did a test for changing DrawElementsUShort to
DrawElementsUInt in function 'void BuildShapeGeometryVisitor::End()',
everything looks good now.
Thank you!
Cheers,
Li
--
Read this topic online here:
On 28 March 2017 at 16:18, Li Chi wrote:
> Hi Robert,
>
> osgShape does work when use the default columns and rows, but I the number of
> columns and rows is getting bigger, like (380x390) the rendering result is
> getting wrong, like the attached picture.
OK, code
Hi Robert,
osgShape does work when use the default columns and rows, but I the number of
columns and rows is getting bigger, like (380x390) the rendering result is
getting wrong, like the attached picture.
Thank you!
Cheers,
Li
--
Read this topic online here:
Hi Li,
I have just added the StateSetManipulator to the osgshapde example to
see if back face culling is the reason, what I found is that the
windings on the triangles are the reverse of what they should be. Is
this probably down to a recent change to avoid using GL_QUADS for
GLES/GL3 builds.
Hi Li,
How are you rendering the height field?
Does the osgshape example work OK for you?
Robert.
On 28 March 2017 at 15:13, Li Chi wrote:
> Hi Robert,
>
> When I create a heightfield (640x320) the generated mesh distorted, please
> take a look at the attached
Hi Robert,
When I create a heightfield (640x320) the generated mesh distorted, please take
a look at the attached picture.
...
heightfield->allocate(640, 320);
heightfield->setXInterval(1.0f);
heightfield->setYInterval(1.0f);
heightfield->setSkirtHeight(1.0f);
...
Just noticed that DisplaySettings::SHADER_NONE has been quietened down.
Testing afresh...
Cheers,
Philippe
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=70580#70580
___
osg-users mailing list
Hi Stuart,
I don't recall resent changes to the files mentioned in your compiler
output, this makes a bit more difficult to point point what might have
caused this problem.
When was the last time you build OSG master? Was it with the same
OS/Compiler set? Did you come across problems then?
I am testing 3.5.6 under msys2.
osg 3.5.6 compiles fine under msys2, but then compiling osgearth against osg
3.5.6 fails.
The reason of the failure is that osgversion.exe outputs some debug string that
cause osgearth to fail determining the proper osg version.
$ osgversion.exe
OK Robert, will do. Thanks for the insight -gw
Glenn Waldron
On Tue, Mar 28, 2017 at 7:01 AM, Robert Osfield
wrote:
> Hi Glenn,
>
> I don't think the BufferData will be serialized correctly prior to
> 3.5.6 so the second block in your revised code won't help, I would
Hi Robert,
Getting an error with a VC++ 2015 64-bit build on Windows 10:
cd /d
C:\Projects\OSG\OpenSceneGraph.VC.r\OSG\src\osgWrappers\serializers\osgVolume
&& C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\cl.exe/TP -D_CRT_SECURE_NO_DEPRECATE
-D_SCL_SECURE_NO_WARNINGS
Hi All,
I have now merged submissions/PR's and resolved all the build and bug
errors I'm aware of, and have updated ChangeLog and AUTHORS.txt for
3.5.6 dev release,so I'm ready to pull the trigger on the dev release.
If anyone has any issues you've seen let me know. If no problems are
reported
Hi Glenn,
I don't think the BufferData will be serialized correctly prior to
3.5.6 so the second block in your revised code won't help, I would
suggest just leaving your original TextureBuffer serializer
implementation in place for versions prior to 3.5.6.
Cheers,
Robert.
On 27 March 2017 at
Robert,
Only one :) And I will let them know the details. It's only used for
caching, so preserving existing files is not critical.
In the meantime I preserved our "old" way of doing it for pre-3.5.4 version
(before getBufferData was available), and copied your updated method for
3.5.5-3.5.6
Thanks for clarification Stuart, good to hear things working under
VS2015 and 17 :-)
On 27 March 2017 at 15:59, Stuart Mentzer wrote:
> Hi Robert,
>
>
> robertosfield wrote:
>> HI Stuart,
>>
>> On 27 March 2017 at 13:44, Stuart Mentzer <> wrote:
>>
>> > With this fix OSG +
Hi Glenn,
I have just had a look at osgEarth's implementation of the
TextureBuffer serializer and it's different from the core OSG one, the
later is a more complete implementation.
For backwards compatibility of older .osgb/.osgx/.osgt files generated
by osgEarth applications that leverage the
Hi Robert,
robertosfield wrote:
> HI Stuart,
>
> On 27 March 2017 at 13:44, Stuart Mentzer <> wrote:
>
> > With this fix OSG + osgQt master branches build and work fine for my
> > application on Windows 10 with Visual C++ 2015 and Qt 5.8.0.
> >
>
> I haven't done any testing under Windows
Robert,
Yes, it's in the latest stable release - version 2.8.
I will add the versioning to our master branch as well as the 2.8 branch.
Thanks!
Glenn Waldron
On Mon, Mar 27, 2017 at 9:47 AM, Robert Osfield
wrote:
> Hi Glenn,
>
> On 27 March 2017 at 14:22, Glenn
HI Stuart,
On 27 March 2017 at 13:44, Stuart Mentzer wrote:
> With this fix OSG + osgQt master branches build and work fine for my
> application on Windows 10 with Visual C++ 2015 and Qt 5.8.0.
I haven't done any testing under Windows so can't comment on whether
OSG master
Hi Glenn,
On 27 March 2017 at 14:22, Glenn Waldron wrote:
> Agreed, we did this out of temporary necessity; the right thing moving
> forward is for osgEarth to check the OSG version when creating/registering
> the osg::TextureBuffer serializer.
Testing for an OSG version of
Hi Robert,
I've tested the newest code, it looks like the SHADER problem has been solved.
Thank you!
Cheers,
Li
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=70559#70559
___
osg-users mailing
Robert,
Agreed, we did this out of temporary necessity; the right thing moving
forward is for osgEarth to check the OSG version when creating/registering
the osg::TextureBuffer serializer.
Glenn Waldron
On Mon, Mar 27, 2017 at 3:27 AM, Robert Osfield
wrote:
> Hi Li,
Hi Robert,
With this fix OSG + osgQt master branches build and work fine for my
application on Windows 10 with Visual C++ 2015 and Qt 5.8.0.
I also built OSG with Visual C++ 2017 for kicks and it seemed to build cleanly
but I didn't test it with my application because I need osgQt and that
Hi Li,
To resolve the shader selection issue I have replaced the #define/#if
usage with a new DisplaySetttings::setShaderHint() and
OSG_SHADER_HINT=GL2|GL3|GLES2|GLES3|NONE controls that enable one to
toggle the functionality at runtime. This change is now checked into
master. The commit was:
Hi Li,
On 26 March 2017 at 23:26, Li Chi wrote:
> Sorry for bothering, I found the cause of the warning
> "ObjectWrapperManager::addWrapper(): 'osg::TextureBuffer' already exists. ".
>
> Because osgEarth already has the osg::TextureBuffer serializer in
>
Hi Robert,
Sorry for bothering, I found the cause of the warning
"ObjectWrapperManager::addWrapper(): 'osg::TextureBuffer' already exists. ".
Because osgEarth already has the osg::TextureBuffer serializer in
TextureBufferSerializer.cpp file, so when use osg and osgEarth together, the
warning
Hi robert,
Maybe this is a bug, osg::TextBuffer serializer wrapper was called two times.
This is the warning message printed out in console window:
ObjectWrapperManager::addWrapper(): 'osg::TextureBuffer' already exists.
Thank you!
Cheers,
Li
--
Read this topic online here:
Hi Li,
On 25 March 2017 at 16:39, Li Chi wrote:
> Hi Robert,
>
> The following line is still not working.
>
> #define SHADERS_GL2 (!defined(OSG_GL_FIXED_FUNCTION_AVAILABLE) &&
> !defined(OSG_GL3_AVAILABLE) && !defined(OSG_GLES3_AVAILABLE))
>
> #if SHADERS_GL2 // <==
Hi Robert,
The following line is still not working.
#define SHADERS_GL2 (!defined(OSG_GL_FIXED_FUNCTION_AVAILABLE) &&
!defined(OSG_GL3_AVAILABLE) && !defined(OSG_GLES3_AVAILABLE))
#if SHADERS_GL2 // <== still return true (this is wrong)
and besides StateSet.cpp and Font.cpp, I found
Hi Li,
Thanks for the suggestions. I've restructured #defines a bit,
hopefully this will work, I've just checked the following changes into
git master. Could you test this out?
Cheers,
Robert.
$ git diff
diff --git a/src/osg/StateSet.cpp b/src/osg/StateSet.cpp
index 1c939e0..c6285ba 100644
---
Hi Osfield,
I make a series of tests, and maybe the cause of the problem is this:
In a c++ program:
#define OSG_GL_FIXED_FUNCTION_AVAILABLE
#if defined(OSG_GL_FIXED_FUNCTION_AVAILABLE)// <== this line returns true
but if you write like the following lines:
#define
Hi Li,
Thanks. With a quick looks pretty similar to the one I have, but I'm
not seeing these problems. It's end of day here so I will need to
look to it tomorrow.
Cheers,
Robert
On 24 March 2017 at 19:20, Li Chi wrote:
> Hi Robert,
>
> Please take a look at the
Hi Robert,
Please take a look at the attached include/osg/GL file.
Thank you!
Cheers,
Li
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=70541#70541
Attachments:
http://forum.openscenegraph.org//files/5405_1490383185._135.
Hi Li,
On 24 March 2017 at 17:48, Li Chi wrote:
> Just as you said, I comment out #if SHADERS_GL3 AND #elif SHADERS_GL2 's
> codes, recompiling and rerunning, everything looks fine now.
Sounds the #if's at the top of StateSet.cpp aren't choosing the
correct code paths
Hi Robert,
Just as you said, I comment out #if SHADERS_GL3 AND #elif SHADERS_GL2 's codes,
recompiling and rerunning, everything looks fine now.
Thank you!
Cheers,
Li
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=70539#70539
Hi Robert,
just a little side info.
I tried our application with the 3.5.5(?) branch about 2 weeks ago
and everything was fine except hud texts were all coming out in black.
I don't know if that is a useful hint.
Thanks
- Werner -
Am 24.03.2017 um 18:27 schrieb Robert Osfield:
HI Li,
My
HI Li,
My best guess is that the first cut of fallback shaders I've added for
GLES2/GLES3 and GL3core are being enabled accidentally for some
reason. These shaders shaders are add in the
StateSet::setGlobalDefaults() method implementation found in
OpenSceneGraph/src/osg/StateSet.cpp. Could you
Hi Robert,
>> What CMake build options did you select when building?
I'm using the default OPENGL and OSG options, please see the attached file.
>> What type of hardware and drivers are you using?
Display Driver: Intel HD 530 and Nvidia GTX 970m, and I got the same results.
I simply run:
Hi Li,
Thanks for the testing. Strange rendering issues, almost like
fallback shaders are being applied inappropriately.
What CMake build options did you select when building?
What type of hardware and drivers are you using?
Do any of the OSG examples work? Does stats work?
Do previous
Hi,
Please see the attached pictures.
ENV:
Visual Studio 2015
Windows 10
32bit Compile
Thank you!
Cheers,
Li
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=70534#70534
Attachments:
http://forum.openscenegraph.org//files/cow_853.png
Hi,
Would be great to address
https://github.com/openscenegraph/OpenSceneGraph/issues/209 in this release.
Thank you!
Cheers,
Philippe
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=70533#70533
Hi All,
There has been a lot of work done to the OSG over the last couple of
months to improve support for VAO, GL3+, GLES2+GLES3, some pretty big
parts of the OSG internals have been rewritten to enable this. With
the culmination of this work we are now getting close to the next
stable release.
65 matches
Mail list logo