Re: [osg-users] Exporting OpenFlight Models
Hi Dan,
The PR looks like an acceptable level of hackiness to resolve this
problem so I've merged this.
There is limit in how much we should go chasing our tails on this
suff, there is fixed function code all over the OSG so it'd be a
massive undertaking to try and find fall-backs for all these. I would
recommend that users don't use GLCORE unless they need to make it easy
port to GLES2/3 or to have to the latest GL features under OSX where
it's only possible with GLCORE. If you have to use GLCORE then I
think we just need to look at the real trouble points and resolve them
locally - this PR is an example where I think this is acceptable, but
it's not something I'd want to see spread across the whole OSG.
If users really want a clean GL then that's Vulkan, it's what GLCORE
was attempting to achieve but falling along way short. So personally
I'd rather user just leave the legacy features of GL on when using the
OSG if there isn't any pressing need otherwise.
Robert.
On Wed, 27 Jun 2018 at 18:09, Daniel Emminizer, Code 5773
wrote:
>
> Hi Robert,
>
> Tl;dr: I think I found a bug in OpenFlight's FltExportVisitor::isTextured()
> when FFP is disabled. This email explains PR 568 more thoroughly.
>
>
>
> I am having problems saving out OpenFlight models and was hoping someone
> could point out what I'm doing wrong. I think I might have identified a bug
> but would like another set of eyes.
>
> I have an open source FLT that is textured that I'm trying to load, make a
> minor edit to, and save out. My code is simple:
>
> osg::ref_ptr opts = new osgDB::Options;
> opts->setOptionString("keepExternalReferences");
> osg::ref_ptr node = osgDB::readRefNodeFile(argv[1],
> opts.get());
>
> opts = new osgDB::Options;
> bool succeeded = osgDB::writeNodeFile(*node, argv[2], opts.get());
>
> It writes out the geometry, but never writes out the textures. I've spent
> the last couple of hours tracking down why and I think I understand. I'm
> using GL3 / GLCORE mode in OSG 3.6.2-rc2. I think it's important to note
> this because I believe the bug is related to a FFP change with StateSet.
>
> The OpenFlight loader reads the image and the textures just fine, and
> displays them. TexturePalette::readTexture() correctly calls
> setTextureAttributeAndModes() with a valid texture. This ends up calling
> osg::Texture::getModeUsage(), which is responsible for turning on
> GL_TEXTURE_2D.
>
> Later on, the FltExportVisitor only respects a texture if GL_TEXTURE_2D is
> enabled, via FltExportVisitor::isTextured().
>
> But when OSG_GL_FIXED_FUNCTION_AVAILABLE is disabled due to GLCORE profile,
> osg::Texture::getModeUsage() is not defined, so setTextureAttributeandModes()
> never sets the mode on GL_TEXTURE_2D.
>
>
> I think the fix is to update isTextured() to check for presence of a texture
> when OSG_GL_FIXED_FUNCTION_AVAILABLE is not set. Does this seem reasonable?
>
> I have put up a PR to inspect at:
> https://github.com/openscenegraph/OpenSceneGraph/pull/568
>
> I do have workarounds on my side, so this isn't super critical. But I think
> it will impact anyone who uses OSG with GLCORE mode who is trying to export
> FLT files.
>
> Thanks,
>
> - Dan
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LineSegmentIntersector::intersect + performance
Excellent. I tested it and everything seems to work as expected. Thanks for the quick response. BTW: I'm also investigating a way to somehow "cache" the last drawable that we intersected with (terrain only). If this works, it could prove to be a significant performance gain in situations where we simulate ground vehicles or lifeforms (for example), since their speed is relatively slow and the probably of intersecting the same geometry at the next frame is very high. My objective is to try to intersect with the cached drawable first, and there's no intersection then fallback to intersecting the entire terrain. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74198#74198 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Exporting OpenFlight Models
Hi Robert,
Tl;dr: I think I found a bug in OpenFlight's FltExportVisitor::isTextured()
when FFP is disabled. This email explains PR 568 more thoroughly.
I am having problems saving out OpenFlight models and was hoping someone could
point out what I'm doing wrong. I think I might have identified a bug but
would like another set of eyes.
I have an open source FLT that is textured that I'm trying to load, make a
minor edit to, and save out. My code is simple:
osg::ref_ptr opts = new osgDB::Options;
opts->setOptionString("keepExternalReferences");
osg::ref_ptr node = osgDB::readRefNodeFile(argv[1], opts.get());
opts = new osgDB::Options;
bool succeeded = osgDB::writeNodeFile(*node, argv[2], opts.get());
It writes out the geometry, but never writes out the textures. I've spent the
last couple of hours tracking down why and I think I understand. I'm using GL3
/ GLCORE mode in OSG 3.6.2-rc2. I think it's important to note this because I
believe the bug is related to a FFP change with StateSet.
The OpenFlight loader reads the image and the textures just fine, and displays
them. TexturePalette::readTexture() correctly calls
setTextureAttributeAndModes() with a valid texture. This ends up calling
osg::Texture::getModeUsage(), which is responsible for turning on GL_TEXTURE_2D.
Later on, the FltExportVisitor only respects a texture if GL_TEXTURE_2D is
enabled, via FltExportVisitor::isTextured().
But when OSG_GL_FIXED_FUNCTION_AVAILABLE is disabled due to GLCORE profile,
osg::Texture::getModeUsage() is not defined, so setTextureAttributeandModes()
never sets the mode on GL_TEXTURE_2D.
I think the fix is to update isTextured() to check for presence of a texture
when OSG_GL_FIXED_FUNCTION_AVAILABLE is not set. Does this seem reasonable?
I have put up a PR to inspect at:
https://github.com/openscenegraph/OpenSceneGraph/pull/568
I do have workarounds on my side, so this isn't super critical. But I think it
will impact anyone who uses OSG with GLCORE mode who is trying to export FLT
files.
Thanks,
- Dan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Strange behaviour on GBufferCamera with 2 attached osg::Image
Hi Werner, On Wed, 27 Jun 2018 at 15:14, Werner Modenbach wrote: > I'd really like doing that. Unfortunately I'm on Windows and the only > development environment is Qt. > So I cannot even create a small project outside Qt. > But honestly I tend to believe it's something in OSG. > Really the only difference in the 2 versions is the additional attachment of > the depth image. Can you not even build the OSG? All I'm asking for a a tiny osgViewer based example like the rest found in OpenSceneGraph/examples. I'm afraid I'm way too busy to go creating test programs that *might* reproduce a problem that an end user is having in their own code, even if I wan't really busy there is real limit in what others can do to help without you putting some effort in helping them help you. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Strange behaviour on GBufferCamera with 2 attached osg::Image
Hi Robert,
I'd really like doing that. Unfortunately I'm on Windows and the only
development environment is Qt.
So I cannot even create a small project outside Qt.
But honestly I tend to believe it's something in OSG.
Really the only difference in the 2 versions is the additional
attachment of the depth image.
I'm sorry.
- Werner -
Am 27.06.2018 um 16:04 schrieb Robert Osfield:
> HI Werner,
>
> The code looks OK. I don't see any reason why attaching an image to
> both the colour and depth attachments wouldn't work, it's not
> something I have tested out though.
>
> There is chance it's an OSG bug, but perhaps there is something in
> your setup that isn't quite right. It's impossible to know from what
> info I have. Could you create a small test program that tests out
> assigning an image to colour and depth buffers and if this fails then
> share this so others like myself can have a look at it and either spot
> an error on the OSG side or in your code. If it works then this
> simple case might shine a light on what you are doing differently.
>
> Robert.
> On Wed, 27 Jun 2018 at 14:52, Werner Modenbach
> wrote:
>> Hi Robert,
>>
>> I'm sorry, I thougth it's OK like that.
>> Find the definition of the "unknown" method below.
>> I think this shrinks the code to be just OSG, except createScreenQuad() but
>> that should not really matter.
>>
>> Thanks
>>
>> - Werner -
>>
>> Am 27.06.2018 um 15:44 schrieb Robert Osfield:
>>
>> Hi Werner,
>>
>> You appear to be included reference to calls and classes that aren't
>> in the OpenSceneGraph, are you using a 3rd party library that is
>> providing these?
>>
>> At this point I can't see a way of helping you as there bit doing the
>> set up are unknown to us.
>>
>> Robert.
>> On Wed, 27 Jun 2018 at 13:53, Werner Modenbach
>> wrote:
>>
>> Hi all,
>>
>> I found a strange behavior of a GBufferCamera. I want to get the color
>> channel in one image and the depth channel in another image.When
>> What I do:
>>
>> if (!renderImage.valid()) {
>>
>> renderImage = new osg::Image;
>>
>> renderImage->allocateImage(width, height, 1, GL_RGBA,
>> GL_UNSIGNED_BYTE, 1);
>>
>> renderImage->setInternalTextureFormat(GL_RGBA8);
>>
>> }
>>
>> if (includeDepth && !depthImage.valid()) {
>>
>> depthImage = new osg::Image;
>>
>> depthImage->allocateImage(width, height, 1, GL_DEPTH_COMPONENT,
>> GL_FLOAT, 1);
>>
>> renderImage->setInternalTextureFormat(GL_LUMINANCE32F_ARB);
>>
>> }
>>
>> if (!includeDepth)
>> renderCamera =
>> view->createRTTCameraImage(osg::Camera::COLOR_BUFFER, 0, renderImage.get(),
>> true);
>> else
>> renderCamera =
>> view->createRTTCameraGBufferImage(osg::Camera::COLOR_BUFFER0,
>> renderImage.get(), osg::Camera::DEPTH_BUFFER, depthImage.get(),
>>
>> osg::Camera::COLOR_BUFFER1, 0, 0, true);
>>
>> The definition of createRTT...
>>
>> osg::Camera *createRTTCameraGBufferImage(osg::Camera::BufferComponent
>> _bufferType1, osg::Image *_image1,
>> osg::Camera::BufferComponent
>> _bufferType2, osg::Image *_image2,
>> osg::Camera::BufferComponent
>> _bufferType3, osg::Image *_image3,
>> int _orderNumber, bool _isAbsolute,
>> bool _withScreenQuad = true) {
>>
>> osg::ref_ptr camera = new osg::Camera;
>>
>> camera->getOrCreateStateSet()->setGlobalDefaults();
>>
>> camera->setClearColor(osg::Vec4());
>>
>> camera->setClearMask(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
>>
>> camera->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
>>
>> camera->setRenderOrder(osg::Camera::PRE_RENDER, _orderNumber);
>>
>> if (_image1) {
>>
>> camera->setViewport(0, 0, _image1->s(), _image1->t());
>>
>> camera->attach(_bufferType1, _image1);
>>
>> }
>>
>> if (_image2) {
>>
>> camera->setViewport(0, 0, _image2->s(), _image2->t());
>>
>> camera->attach(_bufferType2, _image2 );
>>
>> }
>>
>> if (_image3) {
>>
>> camera->setViewport(0, 0, _image3->s(), _image3->t());
>>
>> camera->attach(_bufferType3, _image3);
>>
>> }
>>
>> if (_isAbsolute) {
>>
>> camera->setReferenceFrame(osg::Transform::ABSOLUTE_RF);
>>
>> camera->setProjectionMatrix(osg::Matrix::ortho2D(0.0, 1.0, 0.0,
>> 1.0));
>>
>> camera->setViewMatrix(osg::Matrix::identity());
>>
>> if (_withScreenQuad) {
>>
>> camera->addChild(createScreenQuad(1.0f, 1.0f));
>>
>> }
>>
>> }
>>
>> return camera.release();
>>
>> }
>>
>> When rendering without depth, I get a correct color channel image.
>> When rendering both, color and depth, the depth image is OK but the color
>> image seems having only the red color information.
>> Are there any
Re: [osg-users] Strange behaviour on GBufferCamera with 2 attached osg::Image
HI Werner,
The code looks OK. I don't see any reason why attaching an image to
both the colour and depth attachments wouldn't work, it's not
something I have tested out though.
There is chance it's an OSG bug, but perhaps there is something in
your setup that isn't quite right. It's impossible to know from what
info I have. Could you create a small test program that tests out
assigning an image to colour and depth buffers and if this fails then
share this so others like myself can have a look at it and either spot
an error on the OSG side or in your code. If it works then this
simple case might shine a light on what you are doing differently.
Robert.
On Wed, 27 Jun 2018 at 14:52, Werner Modenbach
wrote:
>
> Hi Robert,
>
> I'm sorry, I thougth it's OK like that.
> Find the definition of the "unknown" method below.
> I think this shrinks the code to be just OSG, except createScreenQuad() but
> that should not really matter.
>
> Thanks
>
> - Werner -
>
> Am 27.06.2018 um 15:44 schrieb Robert Osfield:
>
> Hi Werner,
>
> You appear to be included reference to calls and classes that aren't
> in the OpenSceneGraph, are you using a 3rd party library that is
> providing these?
>
> At this point I can't see a way of helping you as there bit doing the
> set up are unknown to us.
>
> Robert.
> On Wed, 27 Jun 2018 at 13:53, Werner Modenbach
> wrote:
>
> Hi all,
>
> I found a strange behavior of a GBufferCamera. I want to get the color
> channel in one image and the depth channel in another image.When
> What I do:
>
> if (!renderImage.valid()) {
>
> renderImage = new osg::Image;
>
> renderImage->allocateImage(width, height, 1, GL_RGBA,
> GL_UNSIGNED_BYTE, 1);
>
> renderImage->setInternalTextureFormat(GL_RGBA8);
>
> }
>
> if (includeDepth && !depthImage.valid()) {
>
> depthImage = new osg::Image;
>
> depthImage->allocateImage(width, height, 1, GL_DEPTH_COMPONENT,
> GL_FLOAT, 1);
>
> renderImage->setInternalTextureFormat(GL_LUMINANCE32F_ARB);
>
> }
>
> if (!includeDepth)
> renderCamera =
> view->createRTTCameraImage(osg::Camera::COLOR_BUFFER, 0, renderImage.get(),
> true);
> else
> renderCamera =
> view->createRTTCameraGBufferImage(osg::Camera::COLOR_BUFFER0,
> renderImage.get(), osg::Camera::DEPTH_BUFFER, depthImage.get(),
>
> osg::Camera::COLOR_BUFFER1, 0, 0, true);
>
> The definition of createRTT...
>
> osg::Camera *createRTTCameraGBufferImage(osg::Camera::BufferComponent
> _bufferType1, osg::Image *_image1,
> osg::Camera::BufferComponent
> _bufferType2, osg::Image *_image2,
> osg::Camera::BufferComponent
> _bufferType3, osg::Image *_image3,
> int _orderNumber, bool _isAbsolute,
> bool _withScreenQuad = true) {
>
> osg::ref_ptr camera = new osg::Camera;
>
> camera->getOrCreateStateSet()->setGlobalDefaults();
>
> camera->setClearColor(osg::Vec4());
>
> camera->setClearMask(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
>
> camera->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
>
> camera->setRenderOrder(osg::Camera::PRE_RENDER, _orderNumber);
>
> if (_image1) {
>
> camera->setViewport(0, 0, _image1->s(), _image1->t());
>
> camera->attach(_bufferType1, _image1);
>
> }
>
> if (_image2) {
>
> camera->setViewport(0, 0, _image2->s(), _image2->t());
>
> camera->attach(_bufferType2, _image2 );
>
> }
>
> if (_image3) {
>
> camera->setViewport(0, 0, _image3->s(), _image3->t());
>
> camera->attach(_bufferType3, _image3);
>
> }
>
> if (_isAbsolute) {
>
> camera->setReferenceFrame(osg::Transform::ABSOLUTE_RF);
>
> camera->setProjectionMatrix(osg::Matrix::ortho2D(0.0, 1.0, 0.0, 1.0));
>
> camera->setViewMatrix(osg::Matrix::identity());
>
> if (_withScreenQuad) {
>
> camera->addChild(createScreenQuad(1.0f, 1.0f));
>
> }
>
> }
>
> return camera.release();
>
> }
>
> When rendering without depth, I get a correct color channel image.
> When rendering both, color and depth, the depth image is OK but the color
> image seems having only the red color information.
> Are there any limitations in using 2 images?
>
> Has anybody else had such an effect already or can anybody give me a hint?
>
> Many thanks in advance
>
> - Werner -
>
> Many thanks in advance.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Strange behaviour on GBufferCamera with 2 attached osg::Image
Hi Robert,
I'm sorry, I thougth it's OK like that.
Find the definition of the "unknown" method below.
I think this shrinks the code to be just OSG, except createScreenQuad()
but that should not really matter.
Thanks
- Werner -
Am 27.06.2018 um 15:44 schrieb Robert Osfield:
> Hi Werner,
>
> You appear to be included reference to calls and classes that aren't
> in the OpenSceneGraph, are you using a 3rd party library that is
> providing these?
>
> At this point I can't see a way of helping you as there bit doing the
> set up are unknown to us.
>
> Robert.
> On Wed, 27 Jun 2018 at 13:53, Werner Modenbach
> wrote:
>> Hi all,
>>
>> I found a strange behavior of a GBufferCamera. I want to get the color
>> channel in one image and the depth channel in another image.When
>> What I do:
>>
>> if (!renderImage.valid()) {
>>
>> renderImage = new osg::Image;
>>
>> renderImage->allocateImage(width, height, 1, GL_RGBA,
>> GL_UNSIGNED_BYTE, 1);
>>
>> renderImage->setInternalTextureFormat(GL_RGBA8);
>>
>> }
>>
>> if (includeDepth && !depthImage.valid()) {
>>
>> depthImage = new osg::Image;
>>
>> depthImage->allocateImage(width, height, 1, GL_DEPTH_COMPONENT,
>> GL_FLOAT, 1);
>>
>> renderImage->setInternalTextureFormat(GL_LUMINANCE32F_ARB);
>>
>> }
>>
>> if (!includeDepth)
>> renderCamera =
>> view->createRTTCameraImage(osg::Camera::COLOR_BUFFER, 0, renderImage.get(),
>> true);
>> else
>> renderCamera =
>> view->createRTTCameraGBufferImage(osg::Camera::COLOR_BUFFER0,
>> renderImage.get(), osg::Camera::DEPTH_BUFFER, depthImage.get(),
>>
>> osg::Camera::COLOR_BUFFER1, 0, 0, true);
>>
>> The definition of createRTT...
>>
>> osg::Camera *createRTTCameraGBufferImage(osg::Camera::BufferComponent
>> _bufferType1, osg::Image *_image1,
>> osg::Camera::BufferComponent
>> _bufferType2, osg::Image *_image2,
>> osg::Camera::BufferComponent
>> _bufferType3, osg::Image *_image3,
>> int _orderNumber, bool _isAbsolute,
>> bool _withScreenQuad = true) {
osg::ref_ptrcamera=newosg::Camera;
camera->getOrCreateStateSet()->setGlobalDefaults();
camera->setClearColor(osg::Vec4());
camera->setClearMask(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
camera->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
camera->setRenderOrder(osg::Camera::PRE_RENDER,_orderNumber);
if(_image1){
camera->setViewport(0,0,_image1->s(),_image1->t());
camera->attach(_bufferType1,_image1);
}
if(_image2){
camera->setViewport(0,0,_image2->s(),_image2->t());
camera->attach(_bufferType2,_image2);
}
if(_image3){
camera->setViewport(0,0,_image3->s(),_image3->t());
camera->attach(_bufferType3,_image3);
}
if(_isAbsolute){
camera->setReferenceFrame(osg::Transform::ABSOLUTE_RF);
camera->setProjectionMatrix(osg::Matrix::ortho2D(0.0,1.0,0.0,1.0));
camera->setViewMatrix(osg::Matrix::identity());
if(_withScreenQuad){
camera->addChild(createScreenQuad(1.0f,1.0f));
}
}
returncamera.release();
}
>>
>>
>> When rendering without depth, I get a correct color channel image.
>> When rendering both, color and depth, the depth image is OK but the color
>> image seems having only the red color information.
>> Are there any limitations in using 2 images?
>>
>> Has anybody else had such an effect already or can anybody give me a hint?
>>
>> Many thanks in advance
>>
>> - Werner -
>>
>> Many thanks in advance.
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
*TEXION Software Solutions, Rotter Bruch 26a, D-52068 Aachen*
Phone: +49 241 475757-0
Fax: +49 241 475757-29
Web: http://texion.eu
eMail: i...@texion.eu
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Strange behaviour on GBufferCamera with 2 attached osg::Image
Hi Werner,
You appear to be included reference to calls and classes that aren't
in the OpenSceneGraph, are you using a 3rd party library that is
providing these?
At this point I can't see a way of helping you as there bit doing the
set up are unknown to us.
Robert.
On Wed, 27 Jun 2018 at 13:53, Werner Modenbach
wrote:
>
> Hi all,
>
> I found a strange behavior of a GBufferCamera. I want to get the color
> channel in one image and the depth channel in another image.When
> What I do:
>
> if (!renderImage.valid()) {
>
> renderImage = new osg::Image;
>
> renderImage->allocateImage(width, height, 1, GL_RGBA,
> GL_UNSIGNED_BYTE, 1);
>
> renderImage->setInternalTextureFormat(GL_RGBA8);
>
> }
>
> if (includeDepth && !depthImage.valid()) {
>
> depthImage = new osg::Image;
>
> depthImage->allocateImage(width, height, 1, GL_DEPTH_COMPONENT,
> GL_FLOAT, 1);
>
> renderImage->setInternalTextureFormat(GL_LUMINANCE32F_ARB);
>
> }
>
> if (!includeDepth)
> renderCamera =
> view->createRTTCameraImage(osg::Camera::COLOR_BUFFER, 0, renderImage.get(),
> true);
> else
> renderCamera =
> view->createRTTCameraGBufferImage(osg::Camera::COLOR_BUFFER0,
> renderImage.get(), osg::Camera::DEPTH_BUFFER, depthImage.get(),
>
> osg::Camera::COLOR_BUFFER1, 0, 0, true);
>
> The definition of createRTT...
>
> osg::Camera *createRTTCameraGBufferImage(osg::Camera::BufferComponent
> _bufferType1, osg::Image *_image1,
> osg::Camera::BufferComponent
> _bufferType2, osg::Image *_image2,
>
> osg::Camera::BufferComponent
> _bufferType3, osg::Image *_image3,
>
> int _orderNumber, bool _isAbsolute,
> bool _withScreenQuad = true);
>
>
> When rendering without depth, I get a correct color channel image.
> When rendering both, color and depth, the depth image is OK but the color
> image seems having only the red color information.
> Are there any limitations in using 2 images?
>
> Has anybody else had such an effect already or can anybody give me a hint?
>
> Many thanks in advance
>
> - Werner -
>
> Many thanks in advance.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Build error under Windows? Need feedback from Windows users to understand issue
I just updated VS2017 15.7.3 to 15.7.4 and this still compiles just fine. The entire piece of code worries me, as the position is subtracted from the offset and then just added again. Laurens. On Wed, Jun 27, 2018 at 1:48 PM Björn Blissing wrote: > Hi Robert, > > I have previously built it using Visual Studio 2017 without problems. > > One thing to note is that the user who opened the pull request says he is > using Visual Studio version 15.8. This is a version not yet available > outside the beta program. The latest stable version available for me is > 15.7.4. This might be the reason for his compiler error and also why no one > have reported this earlier. > > Regards, > Björn > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=74189#74189 > > > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Strange behaviour on GBufferCamera with 2 attached osg::Image
Hi all,
I found a strange behavior of a GBufferCamera. I want to get the color
channel in one image and the depth channel in another image.When
What I do:
if(!renderImage.valid()){
renderImage=newosg::Image;
renderImage->allocateImage(width,height,1,GL_RGBA,GL_UNSIGNED_BYTE,1);
renderImage->setInternalTextureFormat(GL_RGBA8);
}
if(includeDepth&&!depthImage.valid()){
depthImage=newosg::Image;
depthImage->allocateImage(width,height,1,GL_DEPTH_COMPONENT,GL_FLOAT,1);
renderImage->setInternalTextureFormat(GL_LUMINANCE32F_ARB);
}
if(!includeDepth)
renderCamera=view->createRTTCameraImage(osg::Camera::COLOR_BUFFER,0,renderImage.get(),true);
else
renderCamera=view->createRTTCameraGBufferImage(osg::Camera::COLOR_BUFFER0,renderImage.get(),osg::Camera::DEPTH_BUFFER,depthImage.get(),
osg::Camera::COLOR_BUFFER1,0,0,true);
The definition of createRTT...
osg::Camera*createRTTCameraGBufferImage(osg::Camera::BufferComponent_bufferType1,osg::Image*_image1,
osg::Camera::BufferComponent_bufferType2,osg::Image*_image2,
osg::Camera::BufferComponent_bufferType3,osg::Image*_image3,
int_orderNumber,bool_isAbsolute,bool_withScreenQuad=true);
When rendering without depth, I get a correct color channel image.
When rendering both, color and depth, the depth image is OK but the
color image seems having only the red color information.
Are there any limitations in using 2 images?
Has anybody else had such an effect already or can anybody give me a hint?
Many thanks in advance
- Werner -
Many thanks in advance.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Build error under Windows? Need feedback from Windows users to understand issue
Hi Robert, I have previously built it using Visual Studio 2017 without problems. One thing to note is that the user who opened the pull request says he is using Visual Studio version 15.8. This is a version not yet available outside the beta program. The latest stable version available for me is 15.7.4. This might be the reason for his compiler error and also why no one have reported this earlier. Regards, Björn -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74189#74189 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Build error under Windows? Need feedback from Windows users to understand issue
Hi Robert, I can vouch that it compiles on MSVC 2015, MSVC 2010, and g++ 4.4. I did not test 2012 or 2013, since I figured 2010 and 2015 ought to cover (2015 is _MSC_VER 1900). I only tested 64 bit variants. I do not have MSVC 2017 to test against. I am also not familiar with the code in question, and we don't directly use the osga plugin in our software so I'm not sure how to test beyond ensuring that it compiles. So it does compile and doesn't break my system, that I can tell. Hope this helps some. - Dan > -Original Message- > From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On > Behalf Of Robert Osfield > Sent: Wednesday, June 27, 2018 7:11 AM > To: OpenSceneGraph Users > Subject: [osg-users] Build error under Windows? Need feedback from > Windows users to understand issue > > Hi All, > > A PR has just been placed on the openscenegraph github repository: > > https://github.com/openscenegraph/OpenSceneGraph/pull/567 > > I am bit surprised by the need for this PR as I had assumed that the > code base was being rested pretty well under Windows with all the > recent stable release work. > > I have asked for the author of the PR for clarification. > > I would like to know form the Windows experts in the community about > whether this PR is perfectly fine, or there is some simpler resolution > for this users build combination. > > As I'm about to make a 3.6.2 I obviously want the code base to be in > place where it's compiling well for a broad range of users, I'm also > keenly aware that a build fix for one user could be a build break for > many others so am super cautious at this point in time. > > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Build error under Windows? Need feedback from Windows users to understand issue
Hi All, A PR has just been placed on the openscenegraph github repository: https://github.com/openscenegraph/OpenSceneGraph/pull/567 I am bit surprised by the need for this PR as I had assumed that the code base was being rested pretty well under Windows with all the recent stable release work. I have asked for the author of the PR for clarification. I would like to know form the Windows experts in the community about whether this PR is perfectly fine, or there is some simpler resolution for this users build combination. As I'm about to make a 3.6.2 I obviously want the code base to be in place where it's compiling well for a broad range of users, I'm also keenly aware that a build fix for one user could be a build break for many others so am super cautious at this point in time. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenSceneGraph-3.6.2 release candidate 2 tagged
Hi All, I have tagged the 3.6.2 release candidate 2: https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.2-rc2 Please test and let us know of success or failures :-) Cheers, Robert. -- Changes since 3.6.2-rc1 Wed, 27 Jun 2018 09:06:58 +0100 Author : Robert Osfield Fixed relaseGLObjects() calls Tue, 26 Jun 2018 20:50:55 +0100 Author : Robert Osfield Merge branch 'OpenSceneGraph-3.6' of https://github.com/openscenegraph/OpenSceneGraph into OpenSceneGraph-3.6 Tue, 26 Jun 2018 20:46:49 +0100 Author : Robert Osfield Replaced creation of a temporary Settings object on the heap with creation on the stack to improve performance Tue, 26 Jun 2018 20:17:07 +0100 Author : OpenSceneGraph git repository Merge pull request #566 from emminizer/fix-gl_rb-in-gluscaleimageGL_RG is now a supported format in gluScaleImage(). Tue, 26 Jun 2018 20:10:51 +0100 Author : Robert Osfield Added GLExtensions::isPointSpriteModeSupported to allow it to be enable for GL versions that support GL_POINT_SPRITE_ARB/GL_POINT_SPRITE_OES Tue, 26 Jun 2018 14:44:34 -0400 Author : Daniel Emminizer GL_RG is now a support format in gluScaleImage(). Mon, 25 Jun 2018 20:02:30 +0100 Author : Robert Osfield Moved osg::clampProjectionMatrix() template from CullVisitor.cpp into include/osg/CullSettings to make it easier to implement custom clampProjectionMatrix callbacks ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Antialising for text
Hi Igor, Once you pick an appropriate font resolution for the size of the text on screen it should be appear pretty smooth. If this isn't happening then we'll need more information about your OSG version, hardware, OS, a screen shot, whether the osgtext example renders decent text. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
