Re: [osg-users] Cheaper way to implement rendering-to-texture and post-processing pipeline?

[Rômulo Cerqueira]

Folks,

is there any example to implement FBO without cameras? Where can I find it?

... 

Thank you!

Cheers,
Rômulo

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73488#73488





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Please test OpenSceneGraph-3.6 branch in prep for 3.6.1

[Daniel Emminizer, Code 5773]

Hi Robert,

> I am not at my dev system right now

No problem, I just didn't want to miss the window for bug reporting.  I'm about 
to head out for the day so I'll put together that PR for the version tomorrow 
morning.


> Given it's just a debug feature it only using the inner text bounding box is 
> OK with me.

Sounds good to me too then.


> I haven't looked at your modified code yet, as a general comment, then more 
> focused a test case is at reproducing
> the problem at hand the easiest it is for me to confirm the issue and then 
> use it as a test case.

Agreed, I've been working on that today.

I think I found the missing link for my significant text issues.  The problem 
is much worse with arial.ttf than it is with the default times.ttf.  Instead of 
seeing a difference of +/- 0.02 units of width, I'm seeing a difference of 3.0 
units of width.  The "Long Text String" text shifts left and right constantly.

I also added a status display text to the lower left that is similar to 
something we're doing in our HUD.  In arial you can see the text bouncing.  If 
you press "2", it changes between Times and Arial:
- Times looks worse than Arial with a drop shadow, at the same font size
- You can see the fading effect in Arial as the text moves left and right

You can also toggle the lower-left corner's drop shadow using the "1" key.  The 
intent is to demonstrate that the shifting text is not due to the shadow as I 
first thought.  It also is intended to demonstrate the visibility problems I am 
having.  We had been using drop shadows to make the text more readable against 
similar colored backgrounds.  But in 3.6, it actually makes it harder to read 
the same text, especially at smaller font size.

You can find demonstrations of this in the attached osgtext.cpp.  Feel free to 
ignore the first attachment -- this includes those changes and more, with only 
the relevant code and not the rest of osgtext.

I hope this example helps demonstrate the problems I'm seeing.

As always, thanks for your time with this issue.

 - Dan

/* OpenSceneGraph example, osgtext.
*
*  Permission is hereby granted, free of charge, to any person obtaining a copy
*  of this software and associated documentation files (the "Software"), to deal
*  in the Software without restriction, including without limitation the rights
*  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
*  copies of the Software, and to permit persons to whom the Software is
*  furnished to do so, subject to the following conditions:
*
*  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
*  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
*  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
*  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
*  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
*  THE SOFTWARE.
*/

#include 
#include 

#include 

#include 
#include 
#include 

#include 
#include 

#include 
#include 



std::string printRightText(double angle)
{
std::stringstream ss;
ss << "Press 2 to change the font between\n"
<< "arial and times.\n"
<< std::fixed << std::setprecision(1) << angle << "\n";
return ss.str();
}

struct UpdateColumnPosition : public osg::Callback
{
UpdateColumnPosition(osgText::Text* leftText, osgText::Text* rightText)
  : angleValue(0.0),
left(leftText),
right(rightText)
{
}

virtual bool run(osg::Object* object, osg::Object* data)
{
angleValue = fmod(angleValue + 1.7, 360.0);
right->setText(printRightText(angleValue));

// Position the text appropriately
left->setPosition(osg::Vec3f(10.0, 10.0, 0.0));
osg::BoundingBox bb = left->getBoundingBox();
const float width = bb.xMax() - bb.xMin();
right->setPosition(osg::Vec3f(10.0 + width + 30.0, 10.0, 0.0));

return traverse(object, data);
}

double angleValue;
osg::ref_ptr left;
osg::ref_ptr right;
};

struct ToggleLeftRightTextSettings : public osgGA::GUIEventHandler
{
ToggleLeftRightTextSettings(osgText::Text* leftText, osgText::Text* 
rightText)
  : left(leftText),
right(rightText),
useShadow(true),
useArial(true)
{
}

virtual bool handle(const osgGA::GUIEventAdapter& ea, 
osgGA::GUIActionAdapter& aa, osg::Object*, osg::NodeVisitor*)
{
if (ea.getEventType() == ea.KEYDOWN)
{
if (ea.getKey() == '1')
{
useShadow = !useShadow;
left->setBackdropType(useShadow ? 
osgText::Text::DROP_SHADOW_BOTTOM_RIGHT : osgText::Text::NONE);
right->setBackdropType(left->getBackdropType());
return true;
}
  

Re: [osg-users] How to set mouse position

[Julien Valentin]

Hi
I'm beginning the implementation of my own StandardManipulator
and would like to make a classic fps controller.
So mouse must stay centered all delta mouse pos be captured
However I found out that requestWarpPointer posts a wrapMouse event both in 
Viewer and GraphicWindows implementations. 
it leads to duplication of the event (which is not so bad) but more dramatic, 
it prevent to recenter mouse without trigger an osgevent.
Is it a desired behavior?


robertosfield wrote:
> HI Michael,
> 
> On 20 December 2012 10:10, michael kapelko < ()> wrote:
> 
> >  Can anyone tell me how to set mouse position in OSG?I tried to google it 
> > up without any success.
> > 
> 
> viewer.requestWarpPointer(x,y);
> 
> Robert.
> 
>  --
> Post generated by Mail2Forum


--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73486#73486





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Please test OpenSceneGraph-3.6 branch in prep for 3.6.1

[Robert Osfield]

HI Daniel,

On 23 April 2018 at 15:25, Daniel Emminizer, Code 5773
 wrote:
> 1) Default GL version with GLCORE
>
> During start-up of most applications we see:
> GL3: Non-GL3 version number: 1.0
>
> I can mitigate this by manually setting OSG_GL_CONTEXT_VERSION=3.3 in 
> environment.  Would it make more sense to, in GLCORE config, to default the 
> DisplaySettings.cpp _glContextVersion to "3.3" instead of "1.0" ?  I can 
> submit a PR if desired.

I am not at my dev system right now so can't do a review of the
possible consequences but as a first pass your suggestion sounds
reasonable.


> 2) osgText backdrop looks very poor with smaller fonts
>
> We have a HUD in our application that uses "normal" sized text -- about what 
> you'd see in a typical console application.  We've been using 
> osgText::Text::DROP_SHADOW_BOTTOM_RIGHT but in 3.6.x it looks much worse than 
> I remember it looking in 3.4.  You can see what I mean by editing osgtext.cpp 
> and adding the DROP_SHADOW_BOTTOM_RIGHT to text5.  It's more apparent with 
> smaller text at about character size 24.
>
> It's almost like there's too much alpha blending in the text and it just 
> isn't crisp and readable.  You can see similar effects with OUTLINE, but it's 
> still nowhere as crisp as NONE.
>
> The osgText demo (even with those edits) does not do justice to the problem 
> I'm seeing.  I'm working on a good demonstration of the problem I'm seeing.

The alpha blending is done in the shader now, all done in the shader
to improve the visual quality of outline and drop shadows.  I
developed it across a range of fonts and sizes.  If there are
particular fonts and sizes that aren't working well then the shaders
may need to be revised.

I haven't looked at your modified code yet, as a general comment, then
more focused a test case is at reproducing the problem at hand the
easiest it is for me to confirm the issue and then use it as a test
case.


> 3) Text Bounding Box calculation changes per frame
>
> I'm seeing incorrect bounding box calculations on text still that uses drop 
> shadows.  This matters for us because we have column based HUD text that 
> depends on the width of the previous column.  I have been able to duplicate 
> this in osgtext.cpp example.  I am attaching a osgtext.cpp that reproduces it 
> with cout statements.
>
> I want to come up with a better example, but in the interest of time I hope 
> this suffices.  In our real code, we're seeing a horizontal shift of 0.5 
> pixels, but the example here only shows a shift of 0.02.  In the real 
> example, the shift is dramatic enough, that when coupled with #2, it looks 
> like the text shimmers bright and dark with the drop shadow showing through 
> sometimes.  It's very distracting, and not seen in the 3.4.
>
> In the change, I added UpdateTextCallback to text5 instance.  It updates the 
> text string, and makes sure the drop shadow is right.  I then call 
> getBoundingBox() and print out xMax() - xMin(), yMax() - yMin(), etc.  If 
> there is no drop shadow, then there's no change in values.  If there is a 
> drop shadow, the values change every frame.
>
> Also, the text's actual drawn bounding area (white square from 
> setDrawMode(TEXT|BOUNDINGBOX)) is correct at all times.  Can you explain why 
> that is not the same bounding area as getBoundingBox(), which does change?  
> Probably a misunderstanding on my part.

Away from my dev machine I can't provide a answer as I'll need to look
at the C++ code to provide a definitive answer. Perhaps a recent bug
fix to handle issue with text bounding boxes more robustly has changed
things for your particular usage case.  Essentially I had to decouple
of the Drawable bounding box from the inner text bounding box so that
outlines and drop shadows didn't causes growth in the overall bounding
box when updating text repeatedly.

> 4) BOUNDINGBOX Draw Mode Offset Issue
>
> This one is completely cosmetic and possibly working as intended.  In 
> osgtext.cpp there's an osg::Sequence that shows alignments around a 
> crosshair.  The RIGHT_BOTTOM text is not lined up with the bounding box 
> square.  Is this intentional?  I attached a screenshot of the blown up 
> portion.  It looks completely aligned with the backdrop disabled (NONE).

The crosshair is really just a debug reference added by a contributor
in the early days of osgText.  It isn't a proper feature that I would
expect to be used in a live application.  Given it's just a debug
feature it only using the inner text bounding box is OK with me.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] EXTERNAL: Re: EXTERNAL: Re: Help on multitexturing..

[Rowley, Marlin R]

Thanks Robert.  I got it working and will do text only for code in the future.

-M


Marlin Rowley
Software Engineer, Staff
[cid:image002.jpg@01D39374.DEC5A2E0]
Missiles and Fire Control
972-603-1931 (office)
214-926-0622 (mobile)
marlin.r.row...@lmco.com

From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Friday, April 20, 2018 2:06 AM
To: OpenSceneGraph Users 
Subject: EXTERNAL: Re: [osg-users] EXTERNAL: Re: Help on multitexturing..

On 19 April 2018 at 20:30, Rowley, Marlin R 
> wrote:
I thought the sampler value was a pointer to a texture?

Where did you get that idea?  None of the OSG example attempt this.  When using 
OpenGL you pass the sampler uniforms as int, when it comes to OpenGL the OSG is 
just a lightweight wrapper around it.


I set the texture unit to 1 because we’ll need the base texture unit 0 later 
on.  My goal is to turn on up to 10 texture units and blend them all together.

To be more clear, he is some more code:

mGroupState = mBoundGeometry->getOrCreateStateSet();
  mGroupState->getOrCreateUniform("BaseTexSampler", 
osg::Uniform::SAMPLER_2D)->set(mBaseColor.get());
  mGroupState->getOrCreateUniform("BaseWeight", 
osg::Uniform::FLOAT)->set(mBaseWeight);
  mGroupState->setTextureAttributeAndModes(BASE_TEXTURE_UNIT, mBaseColor, 
osg::StateAttribute::ON);

This sets the base texture unit 1 to be bound to the mBaseColor (which is a 
osg::ref_ptr) created before the function call.

I tell you want the problem is and you copy and paste more code with that exact 
problem in.  Pass in an int value for the sampler texture unit, so 
BASE_TEXTURE_UNIT, not the texture pointer.
For future reference, could you refrrame from using this black and white 
blocks, it's painful to look at.  Just putting everything in plain texture but 
using indentation for code is perfectly fine.
Robert.

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Please test OpenSceneGraph-3.6 branch in prep for 3.6.1

[Robert Osfield]

Hi Terry,

On 23 April 2018 at 16:12, Terry Welsh  wrote:
> Using the 3.6.0 tag I have crashes whenever an osgText::Text appears
> on screen in my application. The osgtext example just doesn't show
> anything at all and crashes when I press Esc. No problems with
> osgText::Text3D or anything else so far. These problems occur when
> compiling with Visual Studio Community 2017 on Win7. I have not had
> any problems compiling with MS Build Tools on Win10 or any problems on
> Fedora or Ubuntu. Last night while I was sleeping I compiled a debug
> build of 3.6.0, and I'll try to look at it tonight. Do you think any
> of the bug fixes you already made would affect this?

You are the first to report a crash with osgText, so what you find
with your debug version of the OSG will be invaluable.

What graphics hardware are you working with?

I don't think the fixes I made to the OpenSceneGraph branch will fix
anything related to your crash, but you never know we might get lucky
:-)

FYI. the new osgText::Text implementation uses shaders to it's work,
in theory it shouldn't do anything radical without checking the
available functionality, but perhaps your driver/hardware aren't
handled well.

> By the way, the new shaderized Text outlines are very pretty.

That was key deliverable for this work so it's good to hear that you
are seeing an improvement.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Please test OpenSceneGraph-3.6 branch in prep for 3.6.1

[Terry Welsh]

>
> Please let me know of success and failures, or any bugs you've seen in
> 3.6.0 but haven't reported yet :-)
>

Robert,
Using the 3.6.0 tag I have crashes whenever an osgText::Text appears
on screen in my application. The osgtext example just doesn't show
anything at all and crashes when I press Esc. No problems with
osgText::Text3D or anything else so far. These problems occur when
compiling with Visual Studio Community 2017 on Win7. I have not had
any problems compiling with MS Build Tools on Win10 or any problems on
Fedora or Ubuntu. Last night while I was sleeping I compiled a debug
build of 3.6.0, and I'll try to look at it tonight. Do you think any
of the bug fixes you already made would affect this?

By the way, the new shaderized Text outlines are very pretty.
- Terry
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Please test OpenSceneGraph-3.6 branch in prep for 3.6.1

[Daniel Emminizer, Code 5773]

Hi Robert,

> Please let me know of success and failures, or any bugs you've seen in
> 3.6.0 but haven't reported yet :-)

We've had a lot of success, and a couple of minor issues.  Most of our issues 
are with either running in GL Core 3.3, or using osgText.  I'm trying to narrow 
down the scope a bit but thought I should send an email before too long.


1) Default GL version with GLCORE

During start-up of most applications we see:
GL3: Non-GL3 version number: 1.0

I can mitigate this by manually setting OSG_GL_CONTEXT_VERSION=3.3 in 
environment.  Would it make more sense to, in GLCORE config, to default the 
DisplaySettings.cpp _glContextVersion to "3.3" instead of "1.0" ?  I can submit 
a PR if desired.


2) osgText backdrop looks very poor with smaller fonts

We have a HUD in our application that uses "normal" sized text -- about what 
you'd see in a typical console application.  We've been using 
osgText::Text::DROP_SHADOW_BOTTOM_RIGHT but in 3.6.x it looks much worse than I 
remember it looking in 3.4.  You can see what I mean by editing osgtext.cpp and 
adding the DROP_SHADOW_BOTTOM_RIGHT to text5.  It's more apparent with smaller 
text at about character size 24.

It's almost like there's too much alpha blending in the text and it just isn't 
crisp and readable.  You can see similar effects with OUTLINE, but it's still 
nowhere as crisp as NONE.

The osgText demo (even with those edits) does not do justice to the problem I'm 
seeing.  I'm working on a good demonstration of the problem I'm seeing.



3) Text Bounding Box calculation changes per frame

I'm seeing incorrect bounding box calculations on text still that uses drop 
shadows.  This matters for us because we have column based HUD text that 
depends on the width of the previous column.  I have been able to duplicate 
this in osgtext.cpp example.  I am attaching a osgtext.cpp that reproduces it 
with cout statements.

I want to come up with a better example, but in the interest of time I hope 
this suffices.  In our real code, we're seeing a horizontal shift of 0.5 
pixels, but the example here only shows a shift of 0.02.  In the real example, 
the shift is dramatic enough, that when coupled with #2, it looks like the text 
shimmers bright and dark with the drop shadow showing through sometimes.  It's 
very distracting, and not seen in the 3.4.

In the change, I added UpdateTextCallback to text5 instance.  It updates the 
text string, and makes sure the drop shadow is right.  I then call 
getBoundingBox() and print out xMax() - xMin(), yMax() - yMin(), etc.  If there 
is no drop shadow, then there's no change in values.  If there is a drop 
shadow, the values change every frame.

Also, the text's actual drawn bounding area (white square from 
setDrawMode(TEXT|BOUNDINGBOX)) is correct at all times.  Can you explain why 
that is not the same bounding area as getBoundingBox(), which does change?  
Probably a misunderstanding on my part.


4) BOUNDINGBOX Draw Mode Offset Issue

This one is completely cosmetic and possibly working as intended.  In 
osgtext.cpp there's an osg::Sequence that shows alignments around a crosshair.  
The RIGHT_BOTTOM text is not lined up with the bounding box square.  Is this 
intentional?  I attached a screenshot of the blown up portion.  It looks 
completely aligned with the backdrop disabled (NONE).



I'm still working on trying to get an example of #2 together if I can.

Thanks for your time,

 - Dan

/* OpenSceneGraph example, osgtext.
*
*  Permission is hereby granted, free of charge, to any person obtaining a copy
*  of this software and associated documentation files (the "Software"), to deal
*  in the Software without restriction, including without limitation the rights
*  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
*  copies of the Software, and to permit persons to whom the Software is
*  furnished to do so, subject to the following conditions:
*
*  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
*  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
*  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
*  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
*  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
*  THE SOFTWARE.
*/

#include 

#include 
#include 
#include 

#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 

osg::Group* createHUDText()
{

osg::Group* rootNode = new osg::Group;

osg::ref_ptr font = 
osgText::readRefFontFile("fonts/arial.ttf");

//osg::setNotifyLevel(osg::INFO);

osg::Geode* geode  = new osg::Geode;
rootNode->addChild(geode);

float windowHeight = 1024.0f;
float windowWidth = 1280.0f;
float margin = 50.0f;

Re: [osg-users] [vpb] VPB stability, and LODs

[Robert Osfield]

Hi Gooz,

I just checked and I see that I haven't tagged 1.0.0 but I have
created the VirtualPlanetBuilder-1.0 branch, so I'll need to tag this
when I get a chance this week.  The git master version is on 1.1 now.
So it's now it's officially stable, though as it's a quieter annex of
the OSG suite of software it's not something under active development.

VPB master and the 1.0 branch works fine with 3.6 and OSG master, and
should work fine with other relatively recent OSG versions, though I
haven't tested it against 3.2 or 3.0 for a number of years.

To see how to load the highest res tiles have a look at the osgposter
example : OpenSceneGraph/examples/osgpostor.  You have to loaded the
tiles incrementally top down till all the required tiles are loaded
for the view frustum you are using.  There isn't a way to go directly
to the leaves as there is no way to know what the highest res tiles
are for any position on the database as VPB databases can be high res
one area, and low res the next all depending upon the source data.

Robert.



On 23 April 2018 at 06:14, Robert Ched  wrote:
> Hi,
>
> I'm using OpenSceneGraph quite a long time, but iv'e never used VPB because I 
> was not sure that it's stable.
>
> a. Is it ? Current version is 0.x, doesn't that mean that it's not stable ?
> b. Which version of VPB is compatible with which version of OSG ? Does a 
> database created with older versions of VPB is forward compatible with newer 
> OSG versions?
> c. some details : my main usage is doing off screen rendering for imagery. 
> Can I make VPB/OSG load only the final LOD that'll be shown? The loading of 
> intermediate LOD's is useless when rendering offscreen.
>
> Thank you!
>
> Cheers,
> gooz
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=73478#73478
>
>
>
>
>
> ___
> 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] [vpb] VPB stability, and LODs

[Robert Ched]

Hi,

I'm using OpenSceneGraph quite a long time, but iv'e never used VPB because I 
was not sure that it's stable.

a. Is it ? Current version is 0.x, doesn't that mean that it's not stable ?
b. Which version of VPB is compatible with which version of OSG ? Does a 
database created with older versions of VPB is forward compatible with newer 
OSG versions?
c. some details : my main usage is doing off screen rendering for imagery. Can 
I make VPB/OSG load only the final LOD that'll be shown? The loading of 
intermediate LOD's is useless when rendering offscreen.

Thank you!

Cheers,
gooz

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73478#73478





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [build] Building OpenSceneGraph-3.6.0 on Windows 10 with VS2017

[Voerman, L.]

Hi André,

You seem to build your project without a definition of WIN32 - don't do
that.
you say
- C/C++ -> Code Generation -> Runtime Library -> Multi-threaded Debug DLL
(/MD)
that does not exist. The debug switch is /MDd, when linking to the release
libs (osg.lib;osgDB.lib,etc) use  *Multi-threaded DLL (/MD) *

You probably want to use CMake to generate your project file anyway, use
the example CMakeLists.txt in "OpenSceneGraph\examples\osgCMakeExample" to
get started.
Regards, Laurens.

On Fri, Apr 20, 2018 at 6:57 PM, André Martins <
andre.calixto.mart...@gmail.com> wrote:

> Thank you so much for your kind input Ravi and Laurens.
> Thanks to you I managed to compile sucessfully release build of the source
> on VS2017 however, when testing the result I cant seem to compile my own
> project...
>
>
> Project-Properties
> x64
> - General -> Character Set -> Use Multi-Byte Character Set
> - C/C++ -> General -> Additional Include Directories ->
> "C:/OSGraph/build/include”
> - C/C++ -> Code Generation -> Runtime Library -> Multi-threaded Debug DLL
> (/MD)
> - C/C++ -> Language -> Enable Run-Time Type Info -> Yes (/GR)
> - Linker -> General -> Additional Library Directories ->
> "C:/OSGraph/build/lib“
> - Linker -> Input -> Additional Dependencies -> "osg.lib,
> osgAnimation.lib, osgDB.lib, osgFX.lib, osgGA.lib, osgManipulator.lib,
> osgParticle.lib, osgPresentation.lib, osgShadow.lib, osgSim.lib,
> osgTerrain.lib, osgText.lib, osgUI.lib, osgUtil.lib, osgViewer.lib,
> osgVolume.lib, osgWidget.lib, OpenThreads.lib“
>
>
> the code:
>
> Code:
>
> #include osgViewer/Viewer //with square brackets around it
>
> int main(int argc, char *argv[])
> {
> return 0;
> }
>
>
>
>
>
> The compilation result:
>
> Code:
>
> 1>-- Compilação iniciada: Projeto: Project2, Configuração: Debug x64
> --
> 1>main.cpp
> 1>c:\program files (x86)\windows 
> kits\10\include\10.0.16299.0\um\gl\gl.h(1157):
> error C2144: erro de sintaxe: 'void' deve ser precedido por ';'
> 1>c:\program files (x86)\windows 
> kits\10\include\10.0.16299.0\um\gl\gl.h(1157):
> error C4430: faltando especificador de tipo - int assumido. Observação: C++
> não suporta default-int
> 1>c:\program files (x86)\windows 
> kits\10\include\10.0.16299.0\um\gl\gl.h(1158):
> error C2144: erro de sintaxe: 'void' deve ser precedido por ';'
> 1>c:\program files (x86)\windows 
> kits\10\include\10.0.16299.0\um\gl\gl.h(1158):
> error C4430: faltando especificador de tipo - int assumido. Observação: C++
> não suporta default-int
> 1>c:\program files (x86)\windows 
> kits\10\include\10.0.16299.0\um\gl\gl.h(1158):
> error C2086: 'int WINGDIAPI': redefinição
> 1>c:\program files (x86)\windows 
> kits\10\include\10.0.16299.0\um\gl\gl.h(1157):
> note: consulte a declaração de 'WINGDIAPI'
> 1>c:\program files (x86)\windows 
> kits\10\include\10.0.16299.0\um\gl\gl.h(1159):
> error C4430: faltando especificador de tipo - int assumido. Observação: C++
> não suporta default-int
> 1>c:\program files (x86)\windows 
> kits\10\include\10.0.16299.0\um\gl\gl.h(1159):
> error C2086: 'int WINGDIAPI': redefinição
> 1>c:\program files (x86)\windows 
> kits\10\include\10.0.16299.0\um\gl\gl.h(1157):
> note: consulte a declaração de 'WINGDIAPI'
> 1>c:\program files (x86)\windows 
> kits\10\include\10.0.16299.0\um\gl\gl.h(1159):
> error C2146: erro de sintaxe: ';' ausente antes do identificador 'GLboolean'
> 1>c:\program files (x86)\windows 
> kits\10\include\10.0.16299.0\um\gl\gl.h(1160):
> error C2144: erro de sintaxe: 'void' deve ser precedido por ';'
> 1>c:\program files (x86)\windows 
> kits\10\include\10.0.16299.0\um\gl\gl.h(1160):
> error C4430: faltando especificador de tipo - int assumido. Observação: C++
> não suporta default-int
> 1>c:\program files (x86)\windows 
> kits\10\include\10.0.16299.0\um\gl\gl.h(1160):
> error C2086: 'int WINGDIAPI': redefinição
> 1>c:\program files (x86)\windows 
> kits\10\include\10.0.16299.0\um\gl\gl.h(1157):
> note: consulte a declaração de 'WINGDIAPI'
> 1>c:\program files (x86)\windows 
> kits\10\include\10.0.16299.0\um\gl\gl.h(1161):
> error C2144: erro de sintaxe: 'void' deve ser precedido por ';'
> 1>c:\program files (x86)\windows 
> kits\10\include\10.0.16299.0\um\gl\gl.h(1161):
> error C4430: faltando especificador de tipo - int assumido. Observação: C++
> não suporta default-int
> 1>c:\program files (x86)\windows 
> kits\10\include\10.0.16299.0\um\gl\gl.h(1161):
> error C2086: 'int WINGDIAPI': redefinição
> 1>c:\program files (x86)\windows 
> kits\10\include\10.0.16299.0\um\gl\gl.h(1157):
> note: consulte a declaração de 'WINGDIAPI'
> 1>c:\program files (x86)\windows 
> kits\10\include\10.0.16299.0\um\gl\gl.h(1162):
> error C2144: erro de sintaxe: 'void' deve ser precedido por ';'
> 1>c:\program files (x86)\windows 
> kits\10\include\10.0.16299.0\um\gl\gl.h(1162):
> error C4430: faltando especificador de tipo - int assumido. Observação: C++
> não suporta default-int
> 1>c:\program files (x86)\windows 
>