Re: [osg-users] blending on multiple targets

2013-11-08 Thread Bram Vaessen
Hi,

thanks for the reply!

I get the undefined part, that makes sense, but what I still don't understand 
though: I just specify blending (GL_BLEND on) is on in the nodes. But then if I 
do

gl_FragData[0] = vec4(0,0,0,0);

then it doesn't seem to matter anymore what I write to gl_FragData[1[ trough 
gl_FragData[3], because it doesn't seem to write anything to the other buffers, 
or at least I noticed that the alpha value from fragdata 0 seems to have an 
effect on what happens with fragdate 3 in my tests. In my test if I set 
gl_FragData[0] = vec4(0,0,0,0);, then fragdata 3 is also not updated, even if I 
write a pixel with alpha value 1 to it, vec4(1,0,0,1) for example.

to clarify further, what I would like is to use the destination blend, so it 
should only use the alpha from my new pixels to blend, and that goes for all 
buffers. And obviously the alpha value from the fragdata 0 should not effect 
the other buffers.

What would I need to set in osg to make it so?

Thank you!

Cheers,
Bram

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





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


[osg-users] [osgPlugins] OSG 3.2.x slower than OSG 3.0.1??

2013-11-08 Thread Tim Rambau
Hi all,

I successfully build 3.2.1-rc1 on Win7 with MinGW+QtCreator, but all framerates 
are lower than my good old OSG 3.0.1.

I made some side by side tests with different 3D-models and osgviewer-3.0.1 vs. 
osgviewer-3.2.1-rc and the times for draw and GPU are at least doubled!!

Are there any new cmake options I should check?

Thanks for any help!!

Cheers,
Tim

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





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


Re: [osg-users] [osgPlugins] OSG 3.2.x slower than OSG 3.0.1??

2013-11-08 Thread Sebastian Messerschmidt

Hi Tim,

I'm doing the same thing right now. I also experienced some performance 
problems with trunk vs. 3.1.8 on Visual Studio 2010 x64.
Currently I'm rebuilding from scratch, so if there are any news I'll let 
you know.
The major change in the core is related to geometry. But as far as I can 
see this should improve performance rather than reduce it.




Hi all,

I successfully build 3.2.1-rc1 on Win7 with MinGW+QtCreator, but all framerates 
are lower than my good old OSG 3.0.1.

I made some side by side tests with different 3D-models and osgviewer-3.0.1 vs. 
osgviewer-3.2.1-rc and the times for draw and GPU are at least doubled!!

Are there any new cmake options I should check?

Thanks for any help!!

Cheers,
Tim

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





___
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] blending on multiple targets

2013-11-08 Thread Sebastian Messerschmidt

Hi Bram,





Hi,

thanks for the reply!

I get the undefined part, that makes sense, but what I still don't understand 
though: I just specify blending (GL_BLEND on) is on in the nodes. But then if I 
do

gl_FragData[0] = vec4(0,0,0,0);

then it doesn't seem to matter anymore what I write to gl_FragData[1[ trough 
gl_FragData[3], because it doesn't seem to write anything to the other buffers, 
or at least I noticed that the alpha value from fragdata 0 seems to have an 
effect on what happens with fragdate 3 in my tests. In my test if I set 
gl_FragData[0] = vec4(0,0,0,0);, then fragdata 3 is also not updated, even if I 
write a pixel with alpha value 1 to it, vec4(1,0,0,1) for example.
Sorry but you are not nearly providing enough context to understand what 
you are really doing here.
First  of all: In order to get blending working your buffers need to 
have alpha (GL_RGBA).


Also, Do you setup a blendfunction and activate it for the stateset?
I prefer to set the blending at the off-screen camera btw.


to clarify further, what I would like is to use the destination blend, so it 
should only use the alpha from my new pixels to blend, and that goes for all 
buffers. And obviously the alpha value from the fragdata 0 should not effect 
the other buffers.

I don't understand what you mean? Can you point to the blendfunction here?
There is no simple way to blend onyl gl_FragData[0] without touching the 
other buffers. As said before: Blending function is applied to all bound 
buffers.

So design your passes in a way that only the buffer to be blended is bound.


What would I need to set in osg to make it so?


So could try to post your buffer setup and your passes or at least 
create a minimalistic example showing your problem?

A little more context on what you are trying to achieve would be helpful too


Cheers
Sebastian



Thank you!

Cheers,
Bram

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





___
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] [osgPlugins] OSG 3.2.x slower than OSG 3.0.1??

2013-11-08 Thread Robert Osfield
Hi Tim,

As Sebastian mentioned the internals of osg::Geometry have been cleaned up
to remove all the old OpenGL slow paths, there is no a lower CPU overhead
so typically I'd expect better performance from this part of the OSG.

Seeing higher GPU costs would suggest something different is being sent to
OpenGL, perhaps some optimizing of the scene graph is being done
differently.  There weren't any reports of slow downs that I recall in the
run up to OSG-3.2. Given this I would suspect a particular dataset type
that isn't being loaded differently.  As I know nothing about your specific
data I can't say anything more other than ask more questions.

What type of data do you have?

What formats are you loading the data from?

Are the scene stats similar?  Number of vertices/Number of Drawables etc.

Does osgviewer also work slower on your system?


Robert.


On 8 November 2013 09:04, Tim Rambau osgfo...@tevs.eu wrote:

 Hi all,

 I successfully build 3.2.1-rc1 on Win7 with MinGW+QtCreator, but all
 framerates are lower than my good old OSG 3.0.1.

 I made some side by side tests with different 3D-models and
 osgviewer-3.0.1 vs. osgviewer-3.2.1-rc and the times for draw and GPU are
 at least doubled!!

 Are there any new cmake options I should check?

 Thanks for any help!!

 Cheers,
 Tim

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





 ___
 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] [osgPlugins] OSG 3.2.x slower than OSG 3.0.1??

2013-11-08 Thread Tim Rambau
Hi Robert,

I tested some airport models, all OpenFlight with jpeg, png and dds textures.

All statistics (vertices, drawables, etc.) are the same, but interestingly 
event, update and cull are also increased, which maybe points to a not only 
OpenGL related problem?

Thanks!!

Tim

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





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


Re: [osg-users] [osgPlugins] OSG 3.2.x slower than OSG 3.0.1??

2013-11-08 Thread Tim Rambau
Hi Robert,

just a simple textured cube:

EventUpdate

Tim

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





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


Re: [osg-users] [osgPlugins] OSG 3.2.x slower than OSG 3.0.1??

2013-11-08 Thread Robert Osfield
Hi Tim,

For the event, update and cull to be slower I would suspect a build issue.
 You aren't testing an non release build by any chance?

The only other possibility might be worth looking at is the OpenFlight
plugin to see if that isn't doing all the optimization it once was.  I
don't recall any changes that might cause a regression in performance but
it's something that might be worth looking at.

Once way to factor out the OpenFlight loader as possibility is to write
load the models with OSG-3.0.1 and then writing it out to .ive or .osgb
then loading in OSG-3.2 and see if the performance is any different.

In general though, 3.0.x and 3.2.x are pretty similar in most respects.
 It's just a few core API elements that have seen significant changes such
as osg::Geometry, most of the changes in OSG-3.2 will be additional
classes/plugins etc.

Robert.


On 8 November 2013 09:41, Tim Rambau osgfo...@tevs.eu wrote:

 Hi Robert,

 I tested some airport models, all OpenFlight with jpeg, png and dds
 textures.

 All statistics (vertices, drawables, etc.) are the same, but interestingly
 event, update and cull are also increased, which maybe points to a not only
 OpenGL related problem?

 Thanks!!

 Tim

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





 ___
 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] [osgPlugins] OSG 3.2.x slower than OSG 3.0.1??

2013-11-08 Thread Robert Osfield
On 8 November 2013 09:51, Tim Rambau osgfo...@tevs.eu wrote:

 Hi Robert,

 just a simple textured cube:

 EventUpdate


Have no clue what you mean here.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] [osgPlugins] OSG 3.2.x slower than OSG 3.0.1??

2013-11-08 Thread Tim Rambau
Sorry,

first line times from osgviewer 3.0.1
second line times from osgviewer 3.2.1-rc1

Same simple cube model with colored sides for both...

Tim

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





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


Re: [osg-users] blending on multiple targets

2013-11-08 Thread Bram Vaessen

 Also, Do you setup a blendfunction and activate it for the stateset?


No I didn't. The thing is, I made some other shaders for a volume light, and 
there I just enabled blending and it worked as I expected. And to clarify what 
I mean with that: I thought that normal 'standard' blending involved mixing the 
colors something like this:

mix(source.rgb, dest.rgb, dest.a). so in other words, it would use the rgb in 
the framebuffer and mix the color of the new pixels based on the alpha of the 
new pixel (ignoring the alpha value from the source pixel).


 I don't understand what you mean? Can you point to the blendfunction here?
 There is no simple way to blend onyl gl_FragData[0] without touching the 
 other buffers. 


I guess, now I looked at the blend functions of opengl better (sorry I'm kinda 
new with opengl), that I would like a glBlendFunc(GL_ONE_MINUS_DST_ALPHA, 
GL_DST_ALPHA);

Does that make sense? that matched with I said above right?


 As said before: Blending function is applied to all bound 
 buffers.
 


what about glBlendFunci, which enabled different blendings per buffer... or is 
that not supported?


 So could try to post your buffer setup and your passes or at least 
 create a minimalistic example showing your problem?
 A little more context on what you are trying to achieve would be helpful too


I will try to post some code tonight if needed, don't have access to it right 
now.

For context: I am rendering terrain with water. the surface of the water is 
partly transparant. for the part underwater I want to use some form of fog 
effect and for the part above water I use some other 3d fog effect. So if the 
camera is above water and look at the water it need to do the following for 
each pixel:
-start with the terrain color (from rendered terrain)
-apply underwater effect
-apply the semi-transparent water-surface pixel (from rendered water)
-apply above water fog effect

So the thing is: I need both the original rendered terrain pixel and also the 
original rendered water-surface pixel.
so that is why I want to render my terrain and my water-surface to two separate 
buffers, so that in the 'final' shader (the deffered one or however you call 
it) I have access to both the rendered water and the rendered terrain under 
that water and calculate the final pixel in a way that I find logical. I 
understand that there might be tons of other ways to do this, but as I'm pretty 
new I hope to do things first in a way which seems logical to me, before doing 
it some other way that is harder to understand for me. But still if you have a 
better idea on how to do what I want I'm open for it :)

Hope I explained this clear enough!

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





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


Re: [osg-users] [osgPlugins] OSG 3.2.x slower than OSG 3.0.1??

2013-11-08 Thread Stephan Maximilian Huber
HI,

The forum2mail-gateway ate part of Tims message. Here’s the full message quoted 
from the forum:

 just a simple textured cube: 
 
 Event_Update_Cull_Draw_GPU 
 0.01__0.00__0.01__0.08__0.28 
 0.02__0.01__0.05__0.13__0.28 

cheers,

Stephan

Am 08.11.2013 um 12:02 schrieb Tim Rambau osgfo...@tevs.eu:

 Sorry,
 
 first line times from osgviewer 3.0.1
 second line times from osgviewer 3.2.1-rc1
 
 Same simple cube model with colored sides for both...
 
 Tim
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=57133#57133
 
 
 
 
 
 ___
 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] [osgPlugins] OSG 3.2.x slower than OSG 3.0.1??

2013-11-08 Thread Robert Osfield
Hi Tim,

Could you post the model.

Right now my strongest suspicion would be a build issue as there really
isn't any reason why event, update, cullm draw dispatch would be so much
longer on such as simple mode, this traversals are very little or have no
changes at all between 3.0.x and 3.2.x.

Robert.


On 8 November 2013 11:02, Tim Rambau osgfo...@tevs.eu wrote:

 Sorry,

 first line times from osgviewer 3.0.1
 second line times from osgviewer 3.2.1-rc1

 Same simple cube model with colored sides for both...

 Tim

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





 ___
 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] [osgPlugins] OSG 3.2.x slower than OSG 3.0.1??

2013-11-08 Thread Tim Rambau
Hi Robert,

simple cube attached...

Tim.

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





cube.ive
Description: Binary data
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] [osgPlugins] OSG 3.2.x slower than OSG 3.0.1??

2013-11-08 Thread Tim Rambau
Hi all,

I will keep testing, but I think I found my mistake: 
I always used cmake_build_type with MinSizeRel or left this option empty.

Setting cmake_build_type = Release gives OSG a boost... 

Thank for your help!!

Tim

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





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


Re: [osg-users] [osgPlugins] OSG 3.2.x slower than OSG 3.0.1??

2013-11-08 Thread Tim Rambau
Sorry, 

it is me again...  :( 
The cube now works perfectly, but all other OpenFlight and *.ive files are 
still slower under 3.2.1.

And my own application loses one third of its framerate...

Tim

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





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


Re: [osg-users] blending on multiple targets

2013-11-08 Thread Sebastian Messerschmidt

Am 08.11.2013 12:02, schrieb Bram Vaessen:

Also, Do you setup a blendfunction and activate it for the stateset?


No I didn't. The thing is, I made some other shaders for a volume light, and 
there I just enabled blending and it worked as I expected. And to clarify what 
I mean with that: I thought that normal 'standard' blending involved mixing the 
colors something like this:

mix(source.rgb, dest.rgb, dest.a). so in other words, it would use the rgb in 
the framebuffer and mix the color of the new pixels based on the alpha of the 
new pixel (ignoring the alpha value from the source pixel).
You're mixing up source and destination. Source is the incoming color 
(i.e. the color written in the shader), destination the color in the 
buffer (i,e, what was already in the target buffer).

Simple blendigng works with two parameters:

First parameter is the source factor, the second the destination factor,
So for instance glBlendFunc(GL_ONE, GL_ZERO) would take the source * 1.0 
and the target * 0.0. Effectively overwritting the buffer. 
(mix(source.rgb, target, 0.0))
glBlendFunc(GL_ONE, GL_ONE)  therefore would give you mix(source, 
target, 0.5)


There are more parameters which don't use a simple factor, but the 
source and destination colors/alphas to scale contribution of the 
written result. The OpenGL specification shows how to use them to get an 
appropriate result. So you'll have to dig into this.


Anyways, some combinations are not valid. For instance you cannot scale 
your src with GL_SRC_COLOR.







I don't understand what you mean? Can you point to the blendfunction here?
There is no simple way to blend onyl gl_FragData[0] without touching the
other buffers.


I guess, now I looked at the blend functions of opengl better (sorry I'm kinda 
new with opengl), that I would like a glBlendFunc(GL_ONE_MINUS_DST_ALPHA, 
GL_DST_ALPHA);

Does that make sense? that matched with I said above right?
Somehow. Frankly I have to look up the correct blending function every 
time I do something out of the ordinary.

If I'm not mistaken the above equation will effectively write.
vec4(1 - source.a) * source.rgba + vec4(dst.a) * dst.rgba


Another thing to mention is
glBlendFuncSeparate. In OSG its simply the blendfunc with four parameters.
It allows to set different factors for rgb and alpha values. So this 
sounds what you're after.


My suggestion here is to start with a simple task to get used to the 
different blending modes. I found them counter-intuitive in the 
beginning, but actually they are designed pretty smart ;-)








As said before: Blending function is applied to all bound
buffers.



what about glBlendFunci, which enabled different blendings per buffer... or is 
that not supported?
I asked this a while ago. There is no function prototype, so it has to 
be added to the extensions somehow I guess




So could try to post your buffer setup and your passes or at least
create a minimalistic example showing your problem?
A little more context on what you are trying to achieve would be helpful too


I will try to post some code tonight if needed, don't have access to it right 
now.

For context: I am rendering terrain with water. the surface of the water is 
partly transparant. for the part underwater I want to use some form of fog 
effect and for the part above water I use some other 3d fog effect. So if the 
camera is above water and look at the water it need to do the following for 
each pixel:
-start with the terrain color (from rendered terrain)
-apply underwater effect
-apply the semi-transparent water-surface pixel (from rendered water)
-apply above water fog effect

So the thing is: I need both the original rendered terrain pixel and also the 
original rendered water-surface pixel.
so that is why I want to render my terrain and my water-surface to two separate 
buffers, so that in the 'final' shader (the deffered one or however you call 
it) I have access to both the rendered water and the rendered terrain under 
that water and calculate the final pixel in a way that I find logical. I 
understand that there might be tons of other ways to do this, but as I'm pretty 
new I hope to do things first in a way which seems logical to me, before doing 
it some other way that is harder to understand for me. But still if you have a 
better idea on how to do what I want I'm open for it :)


If I got this correctly, you have your terrain-buffer in one texture and 
your water result in another. Then you don't need hw-blending to combine 
them. The pass would simply take both inputs and you can mix them freely 
and write it to your destination buffer. The destination however cannot 
be one of the bound textures. So if you want to reuse one of the buffers 
as final one. you'll have to go with blending.


But seriously, this seems a lot to swallow given your just starting to 
use OSG/OpenGL. Start off with a simpler example to get the blending 
things right ;-)


hth,
cheers
Sebastian


Hope I explained this 

Re: [osg-users] blending on multiple targets

2013-11-08 Thread Bram Vaessen

 You're mixing up source and destination. Source is the incoming color 
 (i.e. the color written in the shader), destination the color in the 
 buffer (i,e, what was already in the target buffer).


you are right, the word destination also makes more sense then :)


 I asked this a while ago. There is no function prototype, so it has to 
 be added to the extensions somehow I guess


I got this in a respons on the open gl forums: If you don't need real blending 
for the buffers you do want to write to, you can simply enable and disable 
blending for each buffer (requires EXT_draw_buffers2, or GL3.0)

is that the extension? or actually that seems like it's only about disabling 
certain buffers (which would be great for my purpose)


 If I got this correctly, you have your terrain-buffer in one texture and 
 your water result in another. hen you don't need hw-blending to combine 
 them. 

No and yes, indeed I do not need or use any Hw blending in the final shader, I 
just use mix() etc. in that shader, that is no problem.
But I don't have the writing to seperate buffers working yet, as I described 
above, but it might be just that I need to activate the correct blending mode 
for all buffers as you said, and use a vec(0,0,0,0) as output when I want to 
leave a buffer as is.



 But seriously, this seems a lot to swallow given your just starting to 
 use OSG/OpenGL. Start off with a simpler example to get the blending 
 things right ;-)


I know what you mean, I do tend to disable almost all stuff in the shaders when 
I start working with something new, so I experiment with very simple shaders to 
investigate what is exactly happening :)

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





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


Re: [osg-users] blending on multiple targets

2013-11-08 Thread Sebastian Messerschmidt

Am 08.11.2013 16:31, schrieb Bram Vaessen:

You still can render to them in separate passes.
1.pass: Render texture to FBO with color buffer1
2.pass: Render water to FBO with color buffer2
3.pass: Combine to result buffer (possibly framebuffer)


hmm yeah interesting... two problems that I would need to overcome then: how to 
do multiple passes in OSg (possibly there is a tutorial for that)
but another problem is: I need to reuse the zbuffer from the terrain render for 
the water render or else it will just render all water pixels, including the 
onces hidden behind the hills of the terrain and such...
is that easy to do?
That's easy. Basically you can simply create multiple cameras, each with 
the rendertargets below them.
If you add the same depth buffer texture to the passes it can be used 
for reading and writing.
I don't have the examples at hand, but there is some multipass/offscreen 
example.


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





___
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] OpenSceneGraph and Mac OS X

2013-11-08 Thread Ronald Aldrich
Hello All,

I'm new to OpenSceneGraph, so please bear with me.

I'm attempting to write a Mac OS X native (cocoa) application that uses 
OpenSceneGraph, and I'm having some difficulty.

I created an XCode project to build OpenSceneGraph as a set of frameworks 
(Using CMake), and I think I was mostly successful at that.

Now, I'm trying to use those frameworks within my own application, and having 
some difficulty.

I've created a class (OSGView) along the lines of the OSGViewerCocoa OSGViewer 
class - simplified, and modified for ARC.  That class doesn't populate the 
scene data, and when the application runs,  a view filled with blue is 
displayed - so good, so far.

Next, I tried to create a triangle mesh to populate the scene data with, and 
that's where my problem occurs - when one of the array objects I created is 
deleted, the application crashes.

I can simplify the problem down to the following:

- (void) test
{
osg::ref_ptrosg::Vec3Array theVertices = new osg::Vec3Array(0);
}

When the Vec3Array is deleted, it crashes at the end of Object::~Object(), with 
the code

Thread 1: EXC_BAD_ACCESS (code=1, address= 0xfff8)

I then thought I'd go back to basics, and build the OSGViewerCocoa example, to 
see how it works, but when I build it, all I get is a unix executable 
(OSGViewerCocoad), which doesn't run because it isn't assembled as a complete 
Mac application.

I suspect that the problem I'm having is caused by a mix of build environments 
- CMake for OpenSceneGraph, and XCode (LLVM) for my application, but I've got 
no idea how to resolve that since CMake doesn't appear to be able to create 
complete applications.

So, does anyone have a suggestion?

TIA,

Ron Aldrich

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