[osg-users] Correct place to check shader compile errors

['James Turner' via OpenSceneGraph Users]

I’m trying to extract shader compile and link info logs at runtime, so I 
can log+report them.

I note osg::Program::getGlProgramInfoLog exists, obviously it takes a 
context ID since the PerContextProgram is what has the actual errors.

Two things I need help with:

1) does the program log also contain shader compile errors, or is this only 
the link log? I don’t see a corresponding APi on osg::Shader, is why I ask

2) *when* can I call the log functions and expect to get valid results? 
Given the OSG drawing model, obviously the log won’t be available 
immediately when creating the Program.. Do I need to use a DrawCallback to 
check the log after the first time the Program has been used?

I looked for examples of using getGlProgramInfoLog but unfortunately 
couldn't find any, maybe pointing me at one would answer both of these 
points.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/437023da-c7b2-4bfb-a6b9-6d6613236e04n%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Correct time to check shader/program info log

[James Turner]

Hello,

I’m trying to extract shader compile and link info logs at runtime, so I can 
log+report them.

I note osg::Program::getGlProgramInfoLog exists, obviously it takes a context 
ID since the PerContextProgram is what has the actual errors.

Two things I need help with:

1) does the program log also contain shader compile errors, or is this only the 
link log? I don’t see a corresponding APi on osg::Shader, is why I ask

2) *when* can I call the log functions and expect to get valid results? Given 
the OSg drawing model, obviously the log won’t be available immediately. Do I 
need to use a DrawCallback to check the log after the first time the Program 
has been used?

I looked for examples of using getGlProgramInfoLog but unfortunately couldn't 
find any, maybe pointing me at one would answer both of these points.

Kind regards,
James Turner

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

[osg-users] Order of event handler evaluation, docs?

[James Turner]

Hi,

Is there any documentation on the order in which osgGA::EventHandlers are 
invoked for a particular (mouse event)?

I’m working on code which has a mixture of handlers set on the Viewer (i.e 
global) but also others attached to geodes and drawables within the scene. I’d 
ideally like to have /some/ global handlers executed before the handlers on 
nodes are considered, but it seems as if by default the global handlers are all 
executed after them?

(I need to do some filtering of events in certain mouse modes, before the nodes 
get a chance to do their various things)

Again not necessarily looking for a complete explanation, just a point to any 
relevant docs.

Kind regards,
James

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

Re: [osg-users] Resizing an FBO camera with OSG 3.2.0

[James Turner]

> On 23 Dec 2017, at 10:45, Wojciech Lewandowski  
> wrote:
> 
> Luckily I was able to quickly locate some code. Its a little different to 
> what I described earlier because its using 2 cull callbacks (no render 
> callback) and dummy group to update PreRenderCamera texture sizes but in 
> general its same approach. I have cleaned it a bit from proprietary stuff. So 
> rather treat it as an example code blurb. I did not try to compile it. But in 
> generally this approach worked for me. I think that cull callback attached to 
> PreRenderGroup can be replaced by some callback in main camera. But for some 
> reason we could not do it (I do not recall why, maybe main cam had some other 
> callbacks attached) and  instead just added it in dummy group.
> 
> Cheers,
> Wojtek Lewandowsk

(just catching up on email after the holidays)

Thanks, that’s a big help indeed.

Kind regards,
James

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

Re: [osg-users] Resizing an FBO camera with OSG 3.2.0

[James Turner]

> On 23 Dec 2017, at 09:28, Wojciech Lewandowski  
> wrote:
> 
> Unfortunately I could not dig out the code I had to solve this problem. But I 
> did fight with it on couple occasions. I do remember that often the solution 
> I adopted had to use 2 callbacks (cull/update callback + prerender/render/or 
> postrender callbace). One update/cull callback was needed to resize textures 
> (they were tied to main window resolution) and second callback to invoke FBO 
> update setup for new sizes. Somehow it was impossible to do that in one shot 
> (probably because I could not access proper RenderStage in cull/update 
> callback). That second callback had to be a camera PreRender or (some earlier 
> render order camera PostRender or some other earlier render order drawable 
> DrawCalback). Role of that second callback was to obtain proper RenderStage 
> for FBO camera and set its _cameraRequiresSetup flag.   Once 
> _cameraRequiresSetup flag was set to true, next rendering traversal was doing 
> the rest. Really setting RenderStage::_cameraRequiresSetup was the crucial 
> ingredient to solve that problem back then.

Thanks, that’s a big help. I was already aware that getting 
‘_cameraRequiresSetup’ flag set was the critical piece - thst’s actually why I 
was trying detach() + attach() since that *should* set _cameraRequiresSetup to 
true. But your point about getting the correct RenderStage makes a lot of 
sense, and might explain the strange things I see indeed. 

> 
> PS. If you are still fighting with it, but may wait till January, send me a 
> private email and I will dig out the code. Unfortunately I cannot do it right 
> away (I am swamped in December) but may be have more time to scan through my 
> backups and find it in January. 

I might do that, but it can wait - thank again for your help.

Kind regards,
James

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

Re: [osg-users] Resizing an FBO camera with OSG 3.2.0

[James Turner]

> On 18 Dec 2017, at 11:51, Robert Osfield  wrote:
> 
>if (modified)
>{
>dirtyAttachmentMap();
>}

Thanks Robert,

Unfortunately this line is the part that I can’t figure out how to replicate in 
OSG-3.2 - resizing the textures is easy enough and I’ve already been doing 
that, but the attachment-map-dirty mechanism seems to go deeper into the render 
pass system.

I did try actually removing and re-adding the attachments to the Camera, to 
trigger the same work as when the attachments are initially made. That compiles 
but doesn’t make any difference alas.

(Something like….)

camera->detach(osg::Camera::COLOR_BUFFER);
camera ->attach(osg::Camera::COLOR_BUFFER, _fboTexture);

Oh well, thanks for the suggestion anyway.

James

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

Re: [osg-users] Resizing an FBO camera with OSG 3.2.0

[James Turner]

> On 8 Dec 2017, at 21:04, James Turner <zakal...@mac.com> wrote:
> 
> Any hints on what else to try, to work-around this behaviour, or other 
> examples of keeping a full-screen FBO camera in sync with 3.2.x, would be 
> most appreciated.


I guess no one here is using 3.2.x any more? Or people are busy, of course.

Unfortunately this is a release blocker for Flightgear continuing to ship on 
older distros, maybe it’s time we require OSG 3.4 but we lose a big chunk of 
Ubuntu users as a consequence.

Kind regards,
James

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

[osg-users] Resizing an FBO camera with OSG 3.2.0

[James Turner]

Hi,

I’m trying to correctly support both OSG 3.2.x and 3.4.x in a codebase (since 
we need to support older versions of Debian / Ubuntu which still ship OSG 3.2.x 
as the supported version)

I have some FBO camera which I’m resizing: in 3.4.x I use 
osg::Camera::resizeAttachments. In 3.2.x there’s no such method of course, so I 
am manually resizing the FBO backing texture via:

_fboTexture->setTextureSize(width, height);
_fboTexture->dirtyTextureObject();

However, after a resize, I still don’t see the contents of the FBO camera 
(everything works as expected if I keep the original window size: these are 
full-screen FBOs so I need to keep them in sync with the main window size).

I’ve look at various pieces of code across the 3.2 branch, and tried a few 
things to no avail: in particular I hoped this might update the attachment data:

detach(osg::Camera::COLOR_BUFFER); 
attach(osg::Camera::COLOR_BUFFER, _fboTexture); 

(on my osg::Camera subclass) but to no avail.

I’ve seen some code which calls:

osgViewer::Renderer::setCameraRequiresSetUp

.. but at least for my FBO camera the renderer is null so this doesn’t work for 
me/

Any hints on what else to try, to work-around this behaviour, or other examples 
of keeping a full-screen FBO camera in sync with 3.2.x, would be most 
appreciated.

Kind regards,
James

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

Re: [osg-users] Qt Quick and Android

[James Turner]

> On 28 Sep 2017, at 08:45, Riccardo Corsi  wrote:
> 
> James can you just confirm that, with the QQuickRenderControl approach, it's 
> no more mandatory to have the main application loop handled by a Qt 
> application class?
> 
> At the time when I wrote https://github.com/rickyviking/qmlosg 
>  (probably it was against Qt 4.8) the 
> only option available was to render custom GL stuff within a QtQuick node, 
> and as such I had opted for osgViewer to render into an FBO created on a 
> separate GL context, to avoid any conflict between the GL state used/updated 
> by OSG and the one used by Qt to render its own widgets.
> 

Uh, these two points are unrelated I think!

First thing - it’s never been necessary to have Qt handle the main application 
loop : so long as you call QCore|Gui\Application ::proccessEvents periodcilly, 
eg once per frame. That’s true since 4.x

Second thing, rendering in QtQuick 1 vs 2 (i.e Qt 4.x vs Qt5) changed 
completed, so yes most concepts are different. There’s several different ways 
to do OSG + QtQuick, some are easy but restrict OSG to rendering in the QtQuick 
render thread, which still gives overlapping of the main-thread and GL drawing. 
What I’m trying with the QQuickRenderControl stuff is to make a maximally 
performance solution for Flightgear which is compatible with /all/ the OSG 
threading modes. At the moment I’m not sure how well I will succeed.

Alas, no one replied to my message here about running tasks before the 
rendering starts, but I think I’ve worked out a solution, with some 
restrictions. I didn’t have time to work on this stuff in the past week, so a 
little more patience is needed before I can try out my theories.

Kind regards,
James___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Qt Quick and Android

[James Turner]

> On 22 Sep 2017, at 20:55, Kamil Zaripov  wrote:
> 
> I don’t sure that using QQuickWindow::beforeRendering() or 
> QQuickWindow::afterRendering() signal will help since it also uses same 
> OpenGL context as Qt Quick Scene Graph, but I will try it.

Is that a problem? Keep in mind you can set any QSurfaceFormat as the default 
(before creating the first QQuickWindow, if you want to work on Mac) and hence 
request an arbitrary frame-buffer format or context profile, with the Qt API, 
and QtQuick can still use it.

(And there is QQuickView::resetOpenGLState to avoid any state pollution)

Of course the QQFBOItem approach is nice if you want to keep the contexts 
separate for some reason.


> 
> Solution that uses QQuickRender sound good, I will lock at FlightGear sources.

The QQuickRenderControl part isn’t pushed to FlightGear yet, I have it on a 
local branch since right now it’s not threadsafe, until I find a safe way to 
run QQuickRenderControl::sync from the OSG graphics thread, but with the main 
thread guaranteed to be locked. I can guess a few solutions to that but I’m 
hoping some people more familiar with the threading in osgViewer[base] will 
have some definitive answers.

BTW both of my solutions above rely on using my GraphicsWindowQt5 which is a 
port+evolution of the old GraphicsWindowQt5 to QWIndow+QOpenGLContext; that 
part /is/ in FlightGear already but I’m still debugging some issues, especially 
mouse-pointer-warping, which FlightGear uses, is not working reliably compared 
to the ‘native’ GraphicsWindows (Cocoa, Win32, X11, etc)

Kind regards,
James___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Running a per-frame task on the graphics thread

[James Turner]

Hello,

Related to my other post about integrations with QtQuick, to achieve optimal 
performance I need to run a task on the graphics thread with some very 
particular timings, and I’m hoping for some advice on the most compatible way 
to achieve that. Especially, I’d like a solution which is compatible with all, 
or most, of the OSG threading modes.

To explain, QtQuick can be rendered in ‘foreign’ rendering contexts and threads 
(such as OSG’s graphics thread). There is a basic render function which does 
the bulk of the drawing, and this does no cross-thread communication; hence 
it’s well suited to be run in a Drawable’s drawImplementation or an osg::Camera 
post-draw callback. And I expect that my QtQuick content will be rendered as a 
HUD or overlay so I expect this part to happen almost at the end of the 
graphics thread’s frame, right before the swap.

However, there is a pre-phase (the sync phase), which needs to be run with the 
main thread blocked, which synchronises data, but may also make OpenGL calls : 
for example creating textures or buffers, or uploading shaders. Often it does 
nothing (if the QtQuick scene didn’t change that frame). What I’d like is for 
the graphics thread (assuming it exists) to run this task as early as possible 
in the frame, and definitely before osgViewer::frame returns; I guess this is 
conceptually the same as waiting on the dynamic objects guard which also blocks 
frame() from returning control to the main thread.

I’ve read the implementation details of osgViewer::frame (and ViewerBase) of 
course, but I’m still not certain what is really the nicest way to achieve what 
I need, while keeping the maximum possible amount of overlap between the main 
thread and graphics thread. (Fortunately I don’t think the cull threads are 
affected at all by this integration)

Any suggestions appreciated!

Kind regards,
James

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

Re: [osg-users] Qt Quick and Android

[James Turner]

> On 19 Sep 2017, at 15:28, Kamil Zaripov  wrote:
> 
> Now I’m trying to build osgqtquick library (or just code that is responsible 
> to create QQuickItem) for Android. However I would like to know is there any 
> library that surely works under desktop platforms (Windows, Linux, macOS) and 
> mobile (Android and maybe iOS)?

There’s another approach you can use, which is simpler than these examples, 
using the beforeRendering hook of QQ2 to run the OSG render frame. I think I 
have an example of that somewhere, but would need to check.

I’m currently working on an integration in the other direction, where QQ2 lives 
in a custom drawable / post-render camera. This uses QQuickRenderControl and 
has the advantage of rendering on the OSG graphics thread, so in theorey it’s 
compatible will all the OSg threading modes and hence offers better 
performance. It does rely on using a forked implementation of GraphcisWindowQt 
based on QWindow and QGOpenGLContext. Some of that code is already public 
(inside FlightGear), the rest should hopfully be published in the next few 
weeks.

Kind regards,
James___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Querying pagedLOD state

[James Turner]

> On 5 Sep 2017, at 14:21, Voerman, L.  wrote:
> 
> the PagedLOD addChild call is made from the main thread ( in 
> DatabasePager::addLoadedDataToSceneGraph called from 
> DatabasePager::updateSceneGraph called from Scene::updateSceneGraph called 
> from Viewer::updateTraversal)
> so there will not be a threading problem if you check the number of children 
> from the main thread.

Ah excellent, thanks for clarifying that!

Kind regards,
James___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Querying pagedLOD state

[James Turner]

Hi,

I’ve done some searching of the OSG examples but didn’t discover a solution 
yet: how do I safely (given threading) query from the main thread, if a 
PagedLOD has loaded it’s content. (Assuming only a single level of detail)

I think I can possibly query the number of children being 0 or 1, but that 
feels potentially a bit hacky? And again I worry about thread-safety; does the 
DatabasePager do some locking to regulate when loaded content is inserted into 
the PagedLOD?

(Note I have many concurrent PagedLODs and I need to know if a particular one 
is finished, I can’t use a global query on the DatabasePager being idle, which 
some OSG examples do)

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

[osg-users] Camera::resizeAttachments + texture rect

[James Turner]

Hi,

I have just been surprised to learn that Camera::resizeAttachments doesn’t 
handle TextureRectangle. Would a patch to change this behaviour be accepted? Or 
is it intentional for some reason?

(Yes the texture coordinates have to be adjusted for a rectangular texture but 
I still prefer that over using a 2D texture with considerable wasted space)

Kind regards,
James

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

[osg-users] Deferring loading in an DB ReaderWriter plugin

[James Turner]

Hi,

I’m looking for some advice on deferring / stalling a DB read request for a 
period of time and then resuming it. (Or some equivalent) This is for a 
download-on-demand thing - inside the readNode() implementation I can detect 
that a given set of files needs to be downloaded, which may take many seconds 
depending on the user’s Internet connection. The download system is already 
separately threaded, but I need a way to suspend the request (or simulate the 
same) and then resume it / resubmit it.

I can imagine various solutions, eg returning a placeholder node and then when 
my download completes, re-running the load but passing in some special info 
including the placeholder as the parent. But I can also guess that this 
scenario is common enough to have some more explicit support in osgDB.

I can also imagine the Pager / Database ’s internal load queue must basically 
do what I need, if I could manipulate it directly. (Cancel the current item, 
stash it somewhere and resubmit when some condition occurs) But I’ve not seen 
any examples of doing that (I am going to look for them now).

So, any advice or thoughts are much appreciated. 

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

Re: [osg-users] Potential fix for osgDB MSVC linkage issues (FORCE:MULTIPLE needed)

[James Turner]

> On 16 Aug 2016, at 13:26, Robert Osfield  wrote:
> 
> Would this change not modify the ABI?

Yes, it would - I didn’t realise ABI compatibility was a goal of the stable 
branches.

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

Re: [osg-users] Potential fix for osgDB MSVC linkage issues (FORCE:MULTIPLE needed)

[James Turner]

> On 16 Aug 2016, at 12:47, Robert Osfield  wrote:
> 
> Thanks now merged into git master.

Thanks! We use the 3.4 branch for FlightGear at the moment - can you 
cherry-pick the fix there or would you prefer another pull request?

Kind regards,
James

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

Re: [osg-users] Potential fix for osgDB MSVC linkage issues (FORCE:MULTIPLE needed)

[James Turner]

> On 9 Aug 2016, at 10:21, Robert Osfield  wrote:
> 
> I'm happy to merge the changes, could you raise a pull request based
> on these changes?

https://github.com/openscenegraph/OpenSceneGraph/pull/115

Kind regards,
James

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

Re: [osg-users] Potential fix for osgDB MSVC linkage issues (FORCE:MULTIPLE needed)

[James Turner]

> On 8 Aug 2016, at 09:57, Trajce Nikolov NICK  
> wrote:
> 
> this was discussed while ago for different versions of Visual Studio and 
> there was a work around (which was not forcing to use force:multiple). Might 
> be worth to look in the archive
> 

I would prefer to fix the underlying issue in osgDB, rather than finding better 
work-arounds. My intuition, but as a non-Windows user it may be wrong, is that 
exporting the ctor / dtor for a class you don’t ‘own’ in a DLL is not 
recommended practice. Again, assuming my change does what I think it does in 
terms of preserving the behaviour and linkage against osgDB for the 
implementations of the osgDB wrapper classes.

Kind regards,
James

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

[osg-users] Potential fix for osgDB MSVC linkage issues (FORCE:MULTIPLE needed)

[James Turner]

Hello,

With recent MSVC versions, we’re obliged to use /FORCE_:MULTIPLE, to work 
around the fact that osgDB.lib includes symbols from std::fstream classes, 
which then causes conflicts when other object files in a target (eg executable) 
being linked use  classes. This slows down linking since incremental 
linking is disabled, and makes our build output very noisy.

After some discussion, I came up with the following fix:


https://github.com/zakalawe/osg/commit/2098c022283f1afeb4bad0ffb4b682b884cc8f32

The idea is to only export the non-inlined symbols from osgDB::ofstream and 
::ifstream, but not to export the entire class, since doing so forces MSVC to 
also export the constructor and destructor for the base class (std::ofstream 
and std::ifstream).

Since we don’t use the osgDB versions of fstream in FlightGear, I can’t check 
if this is backwards compatible for other Windows OSG users, but I am hopeful 
that it is, and hence that this approach could be upstreamed. 

Kind regards,
James

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

Re: [osg-users] Linux packaging: Qt 4 vs 5

[James Turner]

> On 21 Jul 2016, at 07:33, Andre Normann  wrote:
> 
> building OT with QThread support is just one step. You also need to write 
> your own osgQt::GraphicsWindowQt derived class to get threading working. I 
> can not remember who posted this solution, but I think you can find in the 
> mailing list archive. With my solution you can use multi-threading, but you 
> can not switch between multi-threading modes. 
> 

I’ve got a GraphicsWindowQt5 (and a GraphicsWIndowQtQuick derivative) in my 
local tree that does that with multi-threading, and doesn’t require OpenThreads 
using Qt; at least on Mac it seems to work ok. What I’m working on now is an 
adapter to import the osg::GraphicsContext into a QOpenGLContext using the 
setNative API that was added in Qt 5.4; this isn’t required for the window 
classes but opens up another integration strategy.

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

Re: [osg-users] Linux packaging: Qt 4 vs 5

[James Turner]

> On 15 Jul 2016, at 10:45, Robert Osfield  wrote:
> 
> Longer term I think the right solution is to spin out osgQt from the
> core OSG and maitain osgQt or two separate osgQt4 and osgQt5 projects
> and have this maintained by Qt experts in the OSG community rather
> than myself who only a small amount of experience with Qt.
> 
> Potentially we could spin out osgQt for 3.6.  It's short notice, but
> removing things from the core OSG is low risk for the OSG itself, it
> just requires a bit of work from the community and myself to set up
> the osgQt/osgQt4/osgQt5 NodeKit so it can live long and prosper
> outside the core OSG.
> 
> Would anyone like to get involved on the osgQt side?

I’ve been working on improving the Qt5 integration with OSG in a local fork; 
one of the reasons I’ve hesitated about submitting it here is that it would be 
entirely incompatible with the current Qt4-based code in osgQt.

I’m happy to ‘get involved’, but I don’t feel qualified to take ownership of 
the broken-out osgQt code, I’d want someone who knows OGS much more deeply, and 
who is more involved in the community here, to manage that.

Kind regards,
James

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

Re: [osg-users] Regression caused by OSG_PROVIDE_READFILE change

[James Turner]

> On 29 Mar 2016, at 20:26, Robert Osfield  wrote:
> 
> I spotted it, but a little thing call Easter got in the way :-)

I did wonder about making an E_TOO_MUCH_CHOCOLATE joke :)

> 
> Fix now merged and checked into OSG master. 

Great, thank you!

How about the 3.4 branch?

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

Re: [osg-users] Regression caused by OSG_PROVIDE_READFILE change

[James Turner]

Robert, just wondering if you missed this?

Kind regards,
James

> On 26 Mar 2016, at 19:35, James Turner <zakal...@mac.com> wrote:
> 
> I got very lucky, and think I found the problem:
> 
> diff --git a/include/osg/StateSet b/include/osg/StateSet
> index 6546832..f73ffc1 100644
> --- a/include/osg/StateSet
> +++ b/include/osg/StateSet
> @@ -238,7 +238,7 @@ class OSG_EXPORT StateSet : public Object
> /** Set this StateSet to contain specified attribute and set the 
> associated GLMode's to specified value.*/
> void setTextureAttributeAndModes(unsigned int unit,StateAttribute 
> *attribute, StateAttribute::GLModeValue value=StateAttribute::ON);
> 
> -template void setTextureAttributeAndModes(unsigned int 
> unit, const ref_ptr& attribute, StateAttribute::OverrideValue 
> value=StateAttribute::OFF) { setTextureAttributeAndModes( unit, 
> attribute.get(), value); }
> +template void setTextureAttributeAndModes(unsigned int 
> unit, const ref_ptr& attribute, StateAttribute::OverrideValue 
> value=StateAttribute::ON) { setTextureAttributeAndModes( unit, 
> attribute.get(), value); }
> 
> /** remove texture attribute of specified type from StateSet.*/
> void removeTextureAttribute(unsigned int unit, StateAttribute::Type 
> type);
> 
> 
> … this brings the template into line with the non-templated version.
> 
> Kind regards,
> James

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

Re: [osg-users] Regression caused by OSG_PROVIDE_READFILE change

[James Turner]

> On 26 Mar 2016, at 17:14, James Turner <zakal...@mac.com> wrote:
> 
>> Sorry to hear there is a regression.  I've looked at your explanation and 
>> the code you linked to, and the relevant osg::StateSet::set*() methods and 
>> can't spot anything obvious wrong.
> 

I got very lucky, and think I found the problem:

diff --git a/include/osg/StateSet b/include/osg/StateSet
index 6546832..f73ffc1 100644
--- a/include/osg/StateSet
+++ b/include/osg/StateSet
@@ -238,7 +238,7 @@ class OSG_EXPORT StateSet : public Object
 /** Set this StateSet to contain specified attribute and set the 
associated GLMode's to specified value.*/
 void setTextureAttributeAndModes(unsigned int unit,StateAttribute 
*attribute, StateAttribute::GLModeValue value=StateAttribute::ON);
 
-template void setTextureAttributeAndModes(unsigned int unit, 
const ref_ptr& attribute, StateAttribute::OverrideValue 
value=StateAttribute::OFF) { setTextureAttributeAndModes( unit, 
attribute.get(), value); }
+template void setTextureAttributeAndModes(unsigned int unit, 
const ref_ptr& attribute, StateAttribute::OverrideValue 
value=StateAttribute::ON) { setTextureAttributeAndModes( unit, attribute.get(), 
value); }
 
 /** remove texture attribute of specified type from StateSet.*/
 void removeTextureAttribute(unsigned int unit, StateAttribute::Type 
type);


… this brings the template into line with the non-templated version.

Kind regards,
James

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

Re: [osg-users] Regression caused by OSG_PROVIDE_READFILE change

[James Turner]

> On 26 Mar 2016, at 14:22, Robert Osfield  wrote:
> 
> Sorry to hear there is a regression.  I've looked at your explanation and the 
> code you linked to, and the relevant osg::StateSet::set*() methods and can't 
> spot anything obvious wrong.

Thank you for looking, I could have missed something but I’m more confident you 
would have spotted a problem!

> 
> One debug test would be to write out the subgraph that the CanvasImage class 
> creates to a .osgt file and then have a look at the results to see if it 
> makes sense.  You could compare the subgraph generated by the OSG before 
> OSG_PROVIDE_READFILE change.  If there are differences then it points to an 
> issue with one of set methods, and potentially even the exact method that is 
> a problem.

Yes. that should be fairly doable, will try this next.

Kind regards,
James

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

[osg-users] Regression caused by OSG_PROVIDE_READFILE change

[James Turner]

Hello,

I’m seeing a bug with both master (c202e4c37276e56caf650684b92a2d83f5dd5a74) 
and the tip of the 3.4.0 branch (f33c58b2f1899b1328b25956ae49e97e6b85097b), 
where a particular textured quad fails to display its texture since the 
OSG_PROVIDE_READFILE change was made.

I’ve done a history bisect to prove to my satisfaction that this change caused 
the problem, and I see there’s been a couple of follow up fixes: especially the 
fix in commit b07cbc2ca8bbb13fa568eb11623aa6fe22479183 from Jannik Heller about 
StateSet setAttributeAndModes.

However even with those fixes applied, I’m still see a white rectangle where 
previously there was a textured rectangle. I’ve verified the osg::Image is 
loaded correctly, and adjusted my code to use ref-ptrs / 
osgDB::readRefImageFile in case this made any difference, but nothing has 
helped so far. The issue is reproducible on at least Windows, Mac and Linux.

I’ve also reviewed the large OSG_PROVIDE_READFILE change, and I don’t see any 
functional changes, especially since I’m using the default value of 
OSG_PROVIDE_READFILE.

My guess is one of the templates added, is causing some alternative code path 
to be taken that’s upsetting something in the image -> texture -> stateset 
logic.

Any debugging / investigation suggestions to figure this out would be most 
appreciated. Unfortunately I don’t have a minimal test case, the code is deeply 
embedded inside FlightGear’s support library, SimGear. You can see what I guess 
are the most relevant part here:

https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/canvas/elements/CanvasImage.cxx#l112
https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/canvas/elements/CanvasImage.cxx#l466

Nothing in this file has changed in nearly a year, and works fine with OSG 3.2 
/ prior to the problem commit on the on 3.4.0 branch.

Any help or debugging suggestions gratefully received!

Kind regards,
James

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

Re: [osg-users] Visual Studio 2015 dependencies?

[James Turner]

> On 22 Mar 2016, at 12:58, Björn Blissing  wrote:
> 
> I have no problem if a link to the github page gets added to the dependencies 
> section of the osg homepage. But someone with edit permissions have to make 
> the change.

I’m trying to use these scripts at the moment, with some additions for 
FlightGear.

But I’m hitting the problem that the generated FreeType layout is different to 
what OSG expects. Is it supposed to work out of the box, with current FreeType 
version (as recommended on the README) and current OSG?

Also, if this is not the correct place to ask such questions, please let me 
know a better one, I can submit bug reports on GitHub.

Kind regards,
James

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

[osg-users] OSG 3.4 branch build failure in osgViewer/View

[James Turner]

Hi,

With XCode 7 (Apple LLVM version 7.0.2 (clang-700.1.81)) I’m getting a compile 
failure in osgViewer/View, line 130: it looks like the template is wrong, 
currently:

template void setImagePager(const osg::ref_ptr* ip) { 
setImagePager(ip.get()); }

when it should be: (I guess)

template void setImagePager(const osg::ref_ptr& ip) { 
setImagePager(ip.get()); } 

Can anyone else confirm this? I’m surprised no one else is experiencing this.

Kind regards,
James

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

Re: [osg-users] Qt5 integration

[James Turner]

 On 17 Aug 2015, at 17:33, Riccardo Corsi riccardo.co...@kairos3d.it wrote:

Thanks Ricky.

 From my point of view the most desired feature is to be able to integrate a 
 qt scene (a GUI layout or a browser/pdf/svg viewer widget) inside an osg 
 driven application smoothly - i.e. without the need of a Qt application to 
 run as main thread loop, but hiding it as a slave somewhere in an osg 
 module/node, to make those widget pluggable in a regular osg application.



As someone else pointed out, this is a less common scenario for what I’m trying 
to support. What I care more about is people who want to use Qt for the thing 
it’s good at, and integrate OSG within it. So they typically want menus, 
dialogs etc from QWidgets or QQ2 (potentially including Qt Quick Controls). 
That’s the use case I’m focusing on for now.

Hiding Qt introduces a lot of complexity and also trades that rather detailed, 
tailored Qt event loops on each platform, for the rather basic ones in each of 
the GraphicsWindow subclasses. 

 Instead if you're interested, a while ago I coded an integration to render 
 with osg inside a QtQuick+QML application.
 Basically the solution implements a custom QtQuick node which renders an 
 osgViewer scene to an FBO, and then copies the FBO contents back to the Qt 
 context, to make it available in the qt/qml scenegraph which renders the 
 widgets.
 The osgQuickNode uses a separate OpenGL context, not to interfere with the 
 one used by Qt for its own scene rendering. 
 All the code is here: https://github.com/rickyviking/qmlosg 
 https://github.com/rickyviking/qmlosg
 If you have questions about the implementation feel free to write me.

The solution you propose of a custom QtQuick node rendering OSG is definitely 
interesting to me, and I would guess your code is likely 90% the same as what I 
would write, so with your permission I might attempt to merge it with my 
submission, once I have time to review it.

Kind regards,
James___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Qt5 integration

[James Turner]

 On 17 Aug 2015, at 09:48, Alistair Baxter alist...@mve.com wrote:
 
 Our main concern at the moment is that we need a multi-window viewer. Due to 
 the way Qt 5 has a separate opengl render thread per Window, this has meant 
 reimplementing a significant chunk of OSGCompositeViewer in order to get it 
 to work at all, and we are discovering a variety of thread-synchronisation 
 issues.

Alistair, we might need to have an in-depth chat about this, and I have some 
other folks I can ask about it, but there’s no correlation between 
QOpenGLContext (and its associated thread) and QWindow, at least as I 
understand it.

But, I’m unfamiliar with the CompositeViewer, can you outline (in private email 
if needs be) what structure you are trying, and where it’s going wrong? (I 
believe you know my work email if that’s easier, I won’t start the clock since 
this education time project for me… ;)

Kind regards,
James___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Qt5 integration

[James Turner]

 On 18 Aug 2015, at 09:44, John Vidar Larring john.larr...@chyronhego.com 
 wrote:
 
 I've attempted to update the osgQt code to use the new QOpenGLWidget rather 
 than the deprecated QGLWindow currently subclassed, but I've hit a snag with 
 the the order of when when QOpenGLContext is created and when CompositeViewer 
 expects it to be available (Probably a silly mistake that I'm overlooking). 
 Have you had to restructure the osgQt::GraphicsWindow or osgQt::GLWindow 
 class and the osgViewerQt example in any way to get your implementation to 
 work? 

I’ve had to restructure osgViewerQt a little, because I didn’t try to get the 
CompositeViewer working yet.

 
 Also, I would like to know why you chose to use QOpenGLWindow rather 
 QOpenGLWidget considering the Qt documenation below.
 
 From http://doc.qt.io/qt-5/qopenglwidget.html 
 http://doc.qt.io/qt-5/qopenglwidget.html:
 
 Adding a QOpenGLWidget http://doc.qt.io/qt-5/qopenglwidget.html into a 
 window turns on OpenGL-based compositing for the entire window. In some 
 special cases this may not be ideal, and the old QGLWidget-style behavior 
 with a separate, native child window is desired. Desktop applications that 
 understand the limitations of this approach (for example when it comes to 
 overlaps, transparency, scroll views and MDI areas), can use QOpenGLWindow 
 http://doc.qt.io/qt-5/qopenglwindow.html with 
 QWidget::createWindowContainer 
 http://doc.qt.io/qt-5/qwidget.html#createWindowContainer(). This is a 
 modern alternative to QGLWidget and is faster than QOpenGLWidget 
 http://doc.qt.io/qt-5/qopenglwidget.html due to the lack of the additional 
 composition step. It is strongly recommended to limit the usage of this 
 approach to cases where there is no other choice. Note that this option is 
 not suitable for most embedded and mobile platforms, and it is known to have 
 issues on certain desktop platforms (e.g. OS X) too. The stable, 
 cross-platform solution is always QOpenGLWidget 
 http://doc.qt.io/qt-5/qopenglwidget.html.

My personal take is that the QOpenGLWidget approach is inferior to the 
QOpenGLWindow+createWindowContainer approach, because of the slightly rapid way 
it was introduced, and the tradeoffs it makes in composting the different 
elements. However, this is subjective, and I will cheerfully support both, 
because as the documentation you pasted notes, there are cases where each 
approach is better or worse.

Note that from my understanding, the QOpenGLWidget approach will effectively 
force OSG into single threaded mode, becuase tge API gives no control over when 
makeCurrent is called, or which thread paintGL is called on. (But I need to 
check this with some colleagues and lazlo who created the code). In contrast my 
QWindow-based approach supports all the OSG threading modes directly.

I expect to end up with three different window options:

- osgQt::GraphicsWindowQt5 - gives you a QWindow, can be embedded with 
createWindowContainer or used standalone

(QtGui dependency only)

- osgQt::GraphicsWidget - gives you a QOpenGLWidget

(QtWidget dependency)

- osgQt::GraphicsWindowQtQuick - gives a window similar to 
QQuickWindow/QQuickView which can have a QML file setSource()-ed on it

(QtGui + QtQuick2 dependency)

I have the first case done, will work on the second and third cases now, before 
worrying about QWidgetImage and other less common forms of integration.

Kind regards,
James

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

[osg-users] Qt5 integration

[James Turner]

Hi,

I’ve been re-working the osgQt code to fit the Qt5 windowing model closer - I 
have a basic proof of concept working, which I will clean up and publish 
shortly. This provides an osgViewer backed by a QWindow; so the widget and 
opengl module dependency is gone, the only Qt5 modules needed are Gui and Core.

A QWindow can be embedded in a traditional widget based application using 
QWidget::createWindowContainer; I will create an example of this approach as 
part of my submission. (And the performance of this approach is the same as the 
old QGLWidget inside GraphicsWindowQt).

What I’d like to know, is what other uses cases are relevant for people:

- I could re-create QWidgetImage, but using QWidget::render and avoiding any 
reliance on QGraphicsScene or QGraphicsProxy. If people have uses cases for 
QWidgetImage, that would be good to know. Especially, are you embedding ‘a few 
buttons’ or entire application layouts? Correctly handling keyboard focus is 
obviously something that’s been difficult in the current code and I expect to 
be similarly awkward.

- QtQuick2 integration; I’ll create a custom QQ2 item which renders OSG via a 
framebuffer. This will allow an OSG scene to be integrated with QQ2 UI, with 
reasonable performance. I would welcome any input from people who need this, 
and your particular requirements, especially the API for binding the osg Scene 
to the QML item. But, see the next point:

- I /hope/ to create a GraphicsWindowQtQuick which allows the common case of an 
OSG scene, with a QQ2 scene overlaid. This has some complexities to support the 
different OSG threading models and context lifetime, but it feels like such a 
common and desirable use case it’s worth spending time on.

- does anyone have a use for an equivalent of QWidgetImage for QtQuick2? I.e a 
chunk of QQ2 content displayed as a texture.

My intention would be to have any new classes live alongside the existing Qt4 
support, since I don’t want to touch that code at all, for fear of regressing 
some aspect of the Qt4 support which someone may be relying upon in existing 
code.

If you have thoughts in this area, interesting requirements which might guide 
my approach, or test-case you can share, please let me know. I will definitely  
be doing the basic pieces outlined above, but whether I work on the 
QWidgetImage piece in particular depends very much on what response I get.

Kind regards,
James Turner

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

Re: [osg-users] Crash in assumeSizedInternalFormat with GL_ALPHA

[James Turner]

On 14 Nov 2014, at 10:49, James Turner zakal...@mac.com wrote:

 I realise my original report was a little lacking in info, I am working to 
 get everything compiled with additional debug / logging so I can verify if 
 the issue is out-of-bounds i value or something else.
 

Converting the loops to forward versions fixed the issue. The problem is size_t 
is unsigned; at the limit condition it doesn’t go negative but wraps around to 
0x …. and boom.

Patch is here (since unsure if attachments are permitted on this list):

http://dpaste.com/32935WT

I have /not/ audited the entire patch for any other similar issues. I am little 
surprised Clang didn’t flag comparison of an unsigned value with =0  - since 
this is a ‘test will always return true’ case which it normally reports on.

Kind regards,
James

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

Re: [osg-users] Crash in assumeSizedInternalFormat with GL_ALPHA

[James Turner]

On 14 Nov 2014, at 09:45, Robert Osfield robert.osfi...@gmail.com wrote:

 I really don't have enough information from your stack trace to know what the 
 problem would be, but from a code review it looks like the i value 
 initialized to a value over the end of the sizedInternalFormats array.  I 
 don't know why Alexander didn't just iterate forwards form i=0; and use a for 
 loop.  
 
 My inclination is to the change the i start value to 0 and use a for loop as 
 it'll make the code both more compact and readable.  If we are to stick with 
 the original code then it would seem like replacing the i initialization with:
 
 size_t i = formatsCount-1 or move the --i to in front of the if statement.  
 Either way it's a bit kludgey.  I regret not reviewing the code a bit more 
 closely now and getting a better explanation of the motivation of each part.  

Well in fairness to Alexander, based on comments in the code, the cases of 
texture format / size are ordered by how likely they are to occur (a subjective 
/ guess-timate definition of course). This is to reduce trips around the loop I 
guess. If you make the loop run forwards instead of back,  you /ought/ to 
invert the order of the arrays, although I suspect in practice this is not a 
hot code path and there is no measurable difference in performance.

I realise my original report was a little lacking in info, I am working to get 
everything compiled with additional debug / logging so I can verify if the 
issue is out-of-bounds i value or something else.

Kind regards,
James

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

[osg-users] Crash in assumeSizedInternalFormat with GL_ALPHA

[James Turner]

Hi,

I’m getting a crash with latest trunk OSG (having not previously updated for 
some time, eg six months or more).

(lldb) bt
* thread #1: tid = 0x24881d, 0x0001040df3c4 
libosg.115.dylib`osg::Texture::applyTexImage2D_load(osg::State, unsigned int, 
osg::Image const*, int, int, int) const [inlined] 
osg::assumeSizedInternalFormat(internalFormat=6406, type=5121) + 4 at 
Texture.cpp:225, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
(code=1, address=0xfffc)
  * frame #0: 0x0001040df3c4 
libosg.115.dylib`osg::Texture::applyTexImage2D_load(osg::State, unsigned int, 
osg::Image const*, int, int, int) const [inlined] 
osg::assumeSizedInternalFormat(internalFormat=6406, type=5121) + 4 at 
Texture.cpp:225
frame #1: 0x0001040df3c0 
libosg.115.dylib`osg::Texture::applyTexImage2D_load(this=0x000104670dc0, 
state=0x000104810800, target=3553, image=0x6180003b2980, inwidth=64, 
inheight=64, numMipmapLevels=8) const + 3360 at Texture.cpp:2284
frame #2: 0x0001040d397f 
libosg.115.dylib`osg::Texture2D::apply(this=0x000104670dc0, 
state=0x000104810800) const + 1695 at Texture2D.cpp:270
frame #3: 0x0001040b49e7 
libosg.115.dylib`osg::State::applyAttributeListOnTexUnit(unsigned int, 


The internalFormat and type values correspond to GL_ALPHA and GL_UNSIGNED_BYTE. 
This case isn’t covered by the sizedInternalFormats array, so one would expect 
the code to have the i counter reach 0, and the function return 0.

This is on clang, Xcode 6.1. Crash is reproducible in all kinds of builds 
(release, debug, rel-with-deb-info) that I tried so far.

Given this code has been in OSG since June according to the blame/log, I guess 
most people are not experiencing the issue, but I thought it best to ask here 
before spending time adding debug logic to the code.

Kind regards,
James

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

Re: [osg-users] Self built 3.2.1 3x slower than repo's 3.2.0

[James Turner]

On 25 Jul 2014, at 07:09, Robert Osfield robert.osfi...@gmail.com wrote:

 No, but when we created the cmake scripts we couldn't find a way of setting 
 it to default on.  I ended up including the cofigure script to workaround 
 this.
 
 We've had cmake for quite a while now so it will have changed substantially 
 since we first adopted so perhaps this inability to set the default will now 
 be gone, or perhaps a bit more experience with cmake magic amongst our 
 community might find a way to do it,  
 

For SimGear / FlightGear we do:

https://gitorious.org/fg/simgear/source/d1f5d92a7bab73d8fd0617d50bbfb7743e2f6565:CMakeLists.txt#L55

Which could equally set a default value instead of warning.

James

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

[osg-users] vertex attribute divisor support

[James Turner]

Hi,

I’ve asked this question in the past, but re-visitng it again: given the lack 
of core support in Array for glVertexAttribDivisor, does anyone have any 
recommendations for getting per-instance data working easily?

I should state that I’m aware of the ‘use a texture and gl_InstanceID to sample 
it in the vertex shader' solution to this, but I need to pass somewhat more 
data than will fit into a standard texture for each instance (3 floats and 
various 8-bit values I could encode into a 32-bit int).

In the refactoring of osg::Geometry, the _DIVISOR_ arguments to Array binding 
were removed, since there was never any backend support, so the only option I 
am sure will work is a custom drawable, where I manually setup the arrays / 
VBOs, call glVertexAttribDivisor myself, and then call glDrawArraysInstanced 
myself. (I.e, bypass Array / PrimitiveSet / all the ArrayDispatcher machinery / 
Geometry:draw)

That feels like a rather excessive amount of work to solve this. Can anyone 
suggest anything simpler? I am aware that floating-point-textures might work to 
store my per-instance data needs, but I don’t have a good feeling for the 
portability of floating-point textures (on desktop hardware), whereas 
glVertexAttribDivisor is supported everywhere I care about. Similarly I’d be 
fine with making a hacked-up subclass of osg::Geometry which lets me bypass the 
ArrayDispatchers and invoke glVertexAttribDivisor myself, but I don’t know if 
that has a chance of working.

Kind regards,
James

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

Re: [osg-users] [osg-submissions] Added CMake options to disable V8, Lua, and Python plugins

[James Turner]

On 30 Jan 2014, at 05:01, Hamm, Brandon brandon.h...@qinetiq-na.com wrote:

 In my case, I had V8 and python libraries available that were being located 
 by CMake, but I did not want to the corresponding OSG plugins to be built 
 with these libraries.  I saw on the osg-users list that someone else was 
 wanting something similar (the ability to turn these plugins off in the 
 build, or rather, a means to exclude them from being generated).  I modified 
 src/osgPlugins/CMakeLists.txt to add the following options:
 
 OSG_BUILD_V8_PLUGIN
 OSG_BUILD_PYTHON_PLUGIN
 OSG_BUILD_LUA_PLUGIN
 
 They are all three ON by default, but can be set to OFF to exclude the 
 respective plugin.
 

I found a different solution which doesn’t require OSG changes at all:

-DCMAKE_DISABLE_FIND_PACKAGE_PythonLibs=1

I was completely unaware of this feature but one of my colleagues is a CMake 
contributor and pointed it out. Essentially you disable and find(Foo) using 
this style, unless it is REQUIRED - the only catch is the capitalization of the 
suffix must match that using in the find() declaration precisely.
 
(Oh and it requires ‘fairly’ recent CMake - 2.8 at least)

Arguably making the options explicit in OSG is nicer to users however, since 
this CMake option is obscure to say the least!

Kind regards,
James

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

Re: [osg-users] [osg-submissions] Changes to make trunk compatible to Visual Studio 2013

[James Turner]

On 22 Nov 2013, at 21:02, Torben Dannhauer tor...@dannhauer.info wrote:

 I’m working on the precompiled dependency package for Visual Studio 2013.

I was trying to build FlightGear using VS 2013 and encountered some of these 
issues, I am glad they are being worked on. 

If you want testing of the package, I would be happy to help.

Kind regards,
James

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

[osg-users] Customising GraphicsWindowWin32 WndProc

[James Turner]

Hi,

I was wondering if anyone has any examples or recommendations to customising 
(replacing) the WndProc in GraphicsWindowWin32? I know how to do it in the 
general case, but some of the code in GraphicsWindow32 makes me wonder if there 
are some special restrictions or a standard approach. (Eg, subclassing 
GraphicsWindowWin32, but I’m unfamiliar with if that is possible and if so how).

(I need to over-ride the non-client-area handling in the default WndProc, since 
it is interfering with my cursor code which is (trying to) bypass the OSG 
handling - as soon as the mouse moves into the NC area the default WndProc is 
resetting things)

Kind regards,
James

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

[osg-users] osg::Geometry with VBOs, compileGLObjects

[James Turner]

Hi,

I’m trying to convert some code (which I’m not the original author of) to use 
VBOs, and encountering some confusion. All of the following is with the respect 
to the OSG 3.2.0 release.

Firstly, am I correct that osg::Geometry::compileGLObjects is required for VBOs 
to function? Or is this purely an optional step?

The motivation for this, is I can see two control-paths which call 
compileGLObjects; the GLObjectsVisitor triggered when the scene is set via 
View::setSceneData - Renderer::setCompileOnNextDraw, and the ‘DoPreCompile’ 
path on the DatabasePager. The Geometry I’m adding above doesn’t enter the 
scene via either of these mechanisms, so as far as I can see from debugging, it 
is never compiled (perhaps this is a bug, and there is something I should be 
doing to force compilation, but I can’t see a safe way to get the Renderer and 
hence invoke setCompileOnNextDraw myself)

Regardless of the answer to the above, are there any additional steps I need 
besides setUseVertexBufferObjects(true) on the osg::Geometry? And is there a 
good way at runtime to verify VBOs are being used successfully, for a 
particular Geometry?

[Note I have verified State::isVertexBufferObjectSupported is returning true, 
so I believe I’m satisfying all the criteria I can see in the code]

Kind regards,
James


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

Re: [osg-users] osg::Geometry with VBOs, compileGLObjects

[James Turner]

On 14 Jan 2014, at 15:45, Robert Osfield robert.osfi...@gmail.com wrote:

 On 14 January 2014 14:29, James Turner zakal...@mac.com wrote:
 Firstly, am I correct that osg::Geometry::compileGLObjects is required for 
 VBOs to function? Or is this purely an optional step?
 
 compileGLObjects() will be called automatically for you, there is rarely need 
 to call it directly, and then only when you want to explicitly compile 
 objects prior to rendering such as when paging, but even then if you use the 
 OSG's built in osgDB::DatabasePager then the pre compile will be do for you 
 anyway.

 I don't know enough about your code to know whether anything is actually 
 being done wrong or going wrong somewhere.
 
 In general you don't need to force a GL boejct compile, it'll happen 
 automatically for you when it comes to rendering the geometry 
 
  There isn't any stats recorded for how many geometries use VBO's but you 
 could easily put a print statement into osg::Geometry/osg::BufferObject to 
 check when code paths it's using, or simply use a debugger and set a 
 breakpoint.
 
 Normally one just needs to setUseVertexBufferObjects(true) and that's it, so 
 it's should be that your app is already using VBO's.  If there anything that 
 makes you think it's not?
 

 I added some very crude changes to Geometry.cpp to test this explicitly. This 
confirmed that in Geometry::drawImplementation, 'usingVertexBufferObjects' is 
true. However, I also tested whether or not compileGLObjects is called, and as 
far as I can tell, it really never is. (Which fits my reading of the code).  
Originally I wondered if the ‘useVertexArrays’ test in that method was failing, 
but actually the whole function is never run. (That’s the result I got from my 
debugger before sending the previous email, but I wasn’t 100% sure the debugger 
wasn’t confused)

What is the mechanism by which the compile step happens for a Geometry (or any 
Drawable) added to the scene after setSceneData and the CompileOnNextDraw 
mechanism? Because I’m not seeing it from a static reading of the code (but of 
course I can have missed it), and the runtime result I observe suggests it’s 
not occurring either.

(Of course, if the compile step isn’t necessary for VBOs to work, this is a 
red-herring anyway)

The meta-point is that I don’t see any performance change when enabling VBOs, 
and the profiler results on Mac suggest that the Geometry in question is still 
on the traditional (non-VBO) glDrawArrays path. In my specific case VBOs may or 
may not help a particular performance problem, but most of the ways I can 
imagine to fix my user-level issue will work much better if VBOs are actually 
working as expected.

Kind regards,
James

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

[osg-users] Disabling Python plugin

[James Turner]

What’s the official way to disable building the Python osgPlugin? (Indeed, 
there doesn’t seem to be a generic way to disable arbitrary plugins at all)

I was looking for a -DOSG_PLUGIN_PYTHON=OFF or similar, I also tried forcing 
some of the variables set by FindPythonLibs.cmake to off/false, but without 
success.

(I’m trying to fix compilation on a Linux target where the FindPythonLibs check 
succeeds, but compiling the plugin fails - and I don’t care about Python 
support, so disabling it seems easiest)

Regards,
James

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

Re: [osg-users] Disabling Python plugin

[James Turner]

On 16 Nov 2013, at 13:12, Robert Osfield robert.osfi...@gmail.com wrote:

 You should be able to disable the plugin by setting the cmake variable 
 generated by the find python to OFF. I am away from my dev machine right now 
 so can’t say exactly what it is called.
 
 

I tried this: -DPYTHONLIBS_FOUND=NO

But with no effect.

 What was the compile error and what version of python do you have installed? 
 Also what disto are you using? I would like to resolve to compile issues/set 
 minimum release version that the Osg can be compiled against,
 
 

You can see the error here:

http://flightgear.simpits.org:8080/job/OSG-svn/lastFailedBuild/console

(Scroll to the bottom of course)

Unfortunately it’s not terribly informative, the cmake output is also quite 
terse:

Found PythonLibs: /usr/lib/python2.5/config/libpython2.5.so

As you can see, this is running on a remote box, a slightly old Fedora install 
I believe, I can tweak the build system to run a verbose build if you are 
interested.
 In general it would be nice to have plugin disable option in cmake.
 
Certainly, but of course this is a larger piece of work for someone to 
volunteer to undertake. In general it would be a cleaner solution for me on 
Mac, where I need to force OSG to ignore various libraries I have installed but 
don’t wish to compile plugins for - Jasper, Qt and so on. (For these ones, 
setting the _FOUND variables to 0 does work)

Kind regards,
James

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

[osg-users] Short-circuiting 3rd party lib detection

[James Turner]

Hello,

I need to short-circuit the CMake detection of FreeType, for annoying reasons 
on Mac (users being pestered to install Xquartz at odd points during the app 
when the osgFT plugin is loaded).

OSG_3RDPARTY_BIN seems like it was designed to do this, based on my reading of 
Find3rdPartyDependencies.cmake, but there's no examples of using it anywhere 
that Google can find. Can someone provide one?

I have:

workspace/dist
lib/
include/
workspace/OpenSceneGraph
(the source checkout)
workspace/osgbuild
(my build dir I'm running cmake from)

'dist' contains the compiled+installed FreeType files. workspace/dist is also 
the CMAKE_INSTALL_PREFIX. I am guessing I can simply set OSG_3RDPARTY_BIN to 
workspace/dist, but I'd like to be sure (I am trying it anyway).

The freetype detection seems a little complex (lots of freetypeXYZ version 
directories being probed), is this to deal with binary freetype releases on 
WIndows maybe?

Regards,
James

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

Re: [osg-users] Short-circuiting 3rd party lib detection

[James Turner]

On 5 Sep 2013, at 17:23, James Turner zakal...@mac.com wrote:

 OSG_3RDPARTY_BIN seems like it was designed to do this, based on my reading 
 of Find3rdPartyDependencies.cmake, but there's no examples of using it 
 anywhere that Google can find. Can someone provide one?

My reading was wrong, I've seen the code that searches sourcedir/../3rdparty 
now. This mechanism seems very Windows-centric, so I'm left wondering the 
correct way to tailor *just* the FreeType detection without disturbing anything 
else.

Regards,
James

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

Re: [osg-users] Short-circuiting 3rd party lib detection

[James Turner]

On 5 Sep 2013, at 17:43, Robert Osfield robert.osfi...@gmail.com wrote:

 If the default Cmake find scripts don't find the lib you are looking from 
 using ccmake . to bring up the console based UI for setting various build 
 variables such as paths to the 3rd Party libs.
 

This is an automated build scenario, so that's not possible unfortunately.  I'm 
investigating if Eric Wing's tweaks to FindFreeType work as described 
(CMAKE_PATH_PREFIX is searched first)

Regards,
James___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] deferred shading in osg

[James Turner]

On 4 Aug 2013, at 23:35, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com 
wrote:

 has anyone has done some work on this and willing to share hints, snippets ?
 

FlightGear has a full deferred renderer ('Rembrandt') implemented using OSG. 
All the code is available of course, in our Git repo.

(Forward or deferred rendering are selected at startup time, so the code is a 
little complex to follow in places - be aware if you're looking at the correct 
code path!)

Regards,
James___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Removing ancient plugins, please read if you want to protect the plugins you need.

[James Turner]

On 18 Jun 2013, at 18:09, Joe Lyga joe.l...@bal4.com wrote:

 We use the .ac plugin very frequently since it's a great simple editor.  
 Please don't remove it!  AC3D isn't an unsupported application anyway, since 
 the latest version was updated in late 2012.
 

FlightGear also is totally reliant on AC3D, for better or worse. Personally I 
think it's a terrible format and would like to move to OBJ, but even if other 
contributors agreed with me (and they don't), we could only machine convert a 
portion of the models (many are authored and hosted externally to the project), 
so we would need a loader for some time. Of course we could maintain the loader 
locally inside FlightGear, but it sounds as if others are also using it.

If maintenance work on the loader is necessary for future osg::Geometry 
changes, please let me know, since FG probably has the largest corpus of AC3D 
test data in existence at this point! - much of it generated by other tools 
besides AC3D itself, such as the blender export script or SketchUp exporter 
plugin (which I'm personally guilty of creating).

Regards,
James

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

Re: [osg-users] Instancing with VertexAttribDivisor

[James Turner]

On 1 Jul 2013, at 17:10, Robert Osfield robert.osfi...@gmail.com wrote:

 To clarify there was never any proper attribute divisor support in the
 OSG, only some enum entries that had no back end support.  All I
 removed today was the enum entries, so just removed the illusion of
 support for attribute divisor.
 
 Once we have a backend implementation then then enum enties can make a
 come back.

Yes, I realised the enums were not doing anything. What I'd like understand is 
the future API for supporting this going forwards, even as a rough sketch.

James

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

Re: [osg-users] Instancing with VertexAttribDivisor

[James Turner]

On 1 Jul 2013, at 14:57, Aurelien Albert aurelien.alb...@alyotech.fr wrote:

 You can still use it by crating a drawcallback (or subclassing a drawable) 
 and call glVertexAttriDivisor were needed.
 
 Just be carefull to reset to previous values brfore exiting the 
 drawImplementation method to not disturb the other nodes rendering.

Sure, my concern isn't so much calling glVertexAttribDivisor manually, as to 
whether I can use the existing Array / PrimitiveSet code to set up the VBOs for 
me, prior to calling glDrawElementsInstanced, or whether I have to revert to 
doing everything myself for the instanced items, in terms of binding vertex 
attributes.  Which would be 'unfortunate'.

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

[osg-users] Instancing with VertexAttribDivisor

[James Turner]

Hi (especially to Aurelien if he's reading),

I'd like to understand the plan for support of instanced drawing in the revised 
Geometry and Array classes, using per-instance attribute arrays via divisors.

Also, if possible, I'd appreciated some suggestions for achieving the same in a 
custom drawable with older versions of OSG (perhaps as far back as 3.0!). I 
have the impression from other posts here that there is some hybrid approach 
where Arrays and PrimitveSets can still be used to specify the repeating 
geometry, but the per-instance attributes being specified manually? A 
pseudo-code, or even working-code example of this, would really enlighten me. 

Note I'm only concerned about platforms with support via 
glVertexAttribDivisor(ARB), since this covers everything I care about in 
practice - even compatibility mode on Apple with GL 2.1 support this via an 
extension.

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

[osg-users] Custom cursors

[James Turner]

There's a commented out method declaration in osgViewer::GraphicsWindow to 
support setting a custom cursor from an osg::Image.

It so happens I really need this functionality - if I was to provide a Cocoa 
implementation, are there people here would might supply corresponding Windows 
and Linux versions? Subject to whatever limitations on size/depth each platform 
imposes.

I have not verified, but I suspect the current (comment out) method parameters 
might be a little narrow; typically cursors require a hot-spot location (X/Y) 
and mask bitmap in addition to the real image, although the mask can be 
expressed via the alpha-channel of course.

I've looked at the corresponding code in Qt 4.8, and at least the Windows 
implementation is doable, if a little verbose - some working with HBITMAPS and 
a Win32 call to create the HCURSOR. X11 I am totally clueless about, I know 
there's different technologies over time (XCursor?) but I've no ideas what is 
current practice or likely to work in the real world on modern distros.

Regards,
James

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

[osg-users] osgText measurement

[James Turner]

Hi,

I'm trying to port some existing code to use osgText instead of a previous 
font-rendering library, and hitting up against the osgText API. In particular, 
I'm struggling to measure text without setting it on a osgText::Text instance.

I guess this is because the font-size and pixel size (and even transformation 
matrix?) must be known to compute a size, but the code I'm coming from 
frequently does things like:

double width = widthOfString(lorum ipsum etc);
// or indeed, height of the string 

if (width  blah) {
... take some action
} else {
... take some radically different action
}

The problem is if start setting line-wrapping or a maximum width on the 
osgText::Text, it seems as if the computed bounding box is going to respect 
those values. I think I need a way to measure the glyph bounds as if line 
wrapping / maximum sizes were ignored. (Without saving / resetting / restoring 
them)

(There's also the issue of needed to create the text-node to perform the 
measurement at all, but I guess I can't escape that)

Am I missing some API features, or is this simply not possible?

BTW, all this text will be drawn with no scaling / rotation, in screen-space, 
with orthographic projection. I realise osgText can't assume that in the 
general case, of course. So, for example, if I could abuse the Font API to 
measure glyph bounds, that might work quite well for me.

James



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

[osg-users] osgWidget complex widgets

[James Turner]

Hi,

I'm experimenting with replacing an existing widget set with versions based on 
osg::Widget. I hope to create most items by composition, eg a scrollbar as two 
end buttons, plus a 'track' and 'thumb', each an osgWidget::Frame or similar, 
arranged in a layout. I was wondering if anyone had any open-source examples of 
this to share? I need to create many standard widgets (such as scrollbars, 
spinboxes, sliders), and unfortunately text-editing widgets as well. The 
osgWidget demos give me everything I strictly *need*, but seeing what other 
people have done would make me more comfortable I'm on a good path :)

Regards,
James

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

[osg-users] Release builds with gcc-llvm on Mac (Xcode 4), cosf/sinf recursion

[James Turner]

I've encountered a problem with the osg/Math header, which a few previous 
emails on this list have alluded to (based on searching the recent archives), 
but which has an interesting explanation.

osg/Math defines the 'f' versions of cos/sin/floor/etc in terms of the double 
versions, on various platforms, including Mac. The implementation is an inline 
function, which casts the input argument, and calls the 'base' version from 
math.h

Unfortunately, LLVM (or the GCC frontend) is smart enough to turn the cast + 
call of the base version back into the floating point version - but the symbol 
look-up then resolves to the osg wrapper - and hence the problem we're seeing. 
Since osg/Math was created, OS-X does define the 'f' versions - but I'm not 
sure which version started doing so - the 10.6 SDK math.h includes the 'f' 
variants, but plain gcc 4.2 wasn't smart enough to turn the cast-to-double + 
call pattern into the float version.

The local workaround is simply to remove the __APPLE__ case around line 48 of 
osg/Math, but really it would be changed to a MAC_OS_X_VERSION_10_z, if someone 
can identify what value 'z' should have. If anyone still has a 10.5 SDK, they 
could check '/usr/include/architecture/i386/math.h' and see if the 'f' variants 
of the math functions are present. 

(What's the minimum version OSG claims to support at this time? 10.5 or still 
holding out with 10.4?)
(Potentially this affects iOS too, though I'm not sure if Apple have enabled 
gcc-llvm for ARM yet, by de default)

James

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

Re: [osg-users] 2.6 Mac OS X issues and some solutions

[James Turner]

On 4 Sep 2008, at 14:34, Eric Sokolowsky wrote:

Yes, for now, the cmake project does not create OSG frameworks.  
We're working on this. Creating dylibs works fine. These dylibs can  
be installed on a developer's system or embedded into an  
application. Since most of the example programs require command-line  
arguments to run properly, it's not too much of a burden to set  
environment variables. Once we get frameworks built with cmake the  
environment variables should not be necessary.


I'd be happy to test any work-in-progress on building frameworks for  
CMake - and since OSG is currently 'unstable' it'd seem like a good  
time to get in into SVN so people can try it and work through and  
problems that arise.


James

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

[osg-users] Sketchup export

[James Turner]

Does anyone here have any experience with getting data from Sketchup  
into OSG? Specifically writing a Sketchup plugin - the SDK examples  
show how to read .skp files in your own code, but I'd sooner be able  
to generate the files from a custom exporter in SketchUp.


Sketchup can already export in .kmz format, which includes models  
as .dae files, i.e Collada 1.4. But I am guessing a plugin for  
sketchup must use some internal API to access the mesh data. I've  
hacked on the OSG Maya exporter in the past, so I know the work  
involved in such a beast isn't huge, but equally, if there's existing  
work out there, I'm happy to take shortcuts.


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

Re: [osg-users] osgdem performance...

[James Turner]

On 15 Aug 2008, at 16:55, Robert Osfield wrote:


I think it was a Z80 system.  The biggest issue hasn't been CPU
bottleneck, but rather than cassette media that isn't well suited to
random access required for paging - it involves careful fast winding
and rewinding on the cassette player to get to the right tile on the
cassette.


BLP!

bzz
bzz
bzz

BLEEP!

Oh, the memories :) I think paging in one background tileset for  
Treasure Island Dizzy was about the limits for the Spectrum.

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

Re: [osg-users] Mac / X-Code build problem

[James Turner]

On 11 Aug 2008, at 16:52, Eric Sokolowsky wrote:

I'm also experiencing some strange crashing in my app under OSX (in  
Leopard). It may be a library initialization issue. (But the same  
code works perfectly under Linux.)


Hmm.

That's a bit worrying, because I'm faced with a large app (FlightGear)  
which is crashing consistently for me in OSG/the gl driver (same place  
each run, at least in release builds - in debug the crash point is  
moving around, but in a way that suggests memory corruption).


The 'good' thing is a binary version (of GF and OSG) someone sent me  
crashes the same way (on my machine), down to the stack-trace level.  
But of course the app works fine under Linux and Windows. I am  
guessing it's a threading or memory corruption issue, but FG is large  
enough that I'm having great trouble isolating the source of the  
problems - any change (adding logging, enabling memory checks with  
MallocScribble, etc) might move the issue.


I've tried forcing OSG into single threaded mode (setting  
OSG_THREADING to SingleThread) but this doesn't help matters.


The bizarre thing is the person who made the binary build, states that  
the build works correctly for him (obviously, or he wouldn't be making  
it available to other people).


Could there be some Leopard issue here? I know dyld changed a fair  
bit, but as I said, I can now run all the OSG examples quite happily.  
Are there any other techniques for isolating portions of the scene  
graph, or its traversal during rendering, to try and isolate the  
issue? Eg an 'only cull' hack?


My gut feeling is it's related to the DB pager (which FG hits very  
hard, especially at startup) since if I hack FG to pause at the end of  
its init process, before it starts running the pager (and other  
things) everything is happy - FG is basically running, the internal  
state looks good, and the osgViewer is running, drawing just the  
splash screen and the UI (which I can interact with quite happily, i.e  
event handling and so on is alright). But this is a guess - again,  
advice on techniques to isolate parts of the rendering / paging /  
loading pipeline would be great. Even with the highest NOTIFY_LEVEL,  
there's nothing in the console output prior to the crash.


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

Re: [osg-users] Mac / X-Code build problem

[James Turner]

On 8 Aug 2008, at 17:10, Eric Sokolowsky wrote:

So, bit of a mystery. I guess I'll build debug, see if I get the  
same issue, then step through the osgDB plugin loading code.
Yes, strange. Let me know what you find. It bothers me that it's not  
Just Working (TM). Are you using Carbon or X11 for  
OSG_WINDOWING_SYSTEM? What is CMAKE_OSX_ARCHITECTURES set to?


Has anyone else tried building and using the recent release on OSX?


Okay, I don't know what happened, but a completely clean build is  
working fine. Apologies for the trouble. Just to be clear, that's on  
two different 10.5 machines, using the CMake build to produce X-Code  
projects, and either not installed, or installed to /usr/local, OSG  
seems to work fine - I played around with many examples.


Annoyingly the app I'm actually trying to get working is still  
crashing in OSG/GL code, but at least I'm now confident it's not OSG  
itself that is the culprit.


Thanks for the advice,
James
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac / X-Code build problem

[James Turner]

On 8 Aug 2008, at 14:43, Eric Sokolowsky wrote:

Hmm. This is very strange. I do not get this problem. The only thing  
that I do differently is that I don't install into /usr/local. Can  
you try running osgviewer from the directory where it is built? You  
may need to set OSG_LIBRARY_PATH to point to your plugins directory.  
Can you also show the results of otool -L /path/to/osgviewer?


Tried using the 'uninstalled' versions, same result.

otool -L gives the following, which all looks sane to me:

MacPro:Release jmt$ otool -L osgviewer
osgviewer:
	/Users/jmt/Code/OSG/build-release/lib/Release/libosgViewer.dylib  
(compatibility version 1.0.0, current version 1.0.0)
	/Users/jmt/Code/OSG/build-release/lib/Release/libosgGA.dylib  
(compatibility version 1.0.0, current version 1.0.0)
	/Users/jmt/Code/OSG/build-release/lib/Release/libosgText.dylib  
(compatibility version 1.0.0, current version 1.0.0)
	/Users/jmt/Code/OSG/build-release/lib/Release/libosgDB.dylib  
(compatibility version 1.0.0, current version 1.0.0)
	/Users/jmt/Code/OSG/build-release/lib/Release/libosgUtil.dylib  
(compatibility version 1.0.0, current version 1.0.0)
	/Users/jmt/Code/OSG/build-release/lib/Release/libosg.dylib  
(compatibility version 1.0.0, current version 1.0.0)
	/Users/jmt/Code/OSG/build-release/lib/Release/libOpenThreads.dylib  
(compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current  
version 111.1.1)
	/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon  
(compatibility version 2.0.0, current version 136.0.0)
	/System/Library/Frameworks/AGL.framework/Versions/A/AGL  
(compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL  
(compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current  
version 7.4.0)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current  
version 1.0.0)


You can also set your OSG_FILE_PATH to point to the OpenSceneGraph- 
Data directory if you don't want to keep typing that path.


Yep,. had actually done that, hadn't realised it worked for command  
line args as well.


So, bit of a mystery. I guess I'll build debug, see if I get the same  
issue, then step through the osgDB plugin loading code.


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

Re: [osg-users] Mac / X-Code build problem

[James Turner]

On 6 Aug 2008, at 22:22, James Turner wrote:

Anyway, thanks for pointing this out. I will go and try a CMake  
build now.


With a Cmake based build of 2.6.0, I can build OSG fine, but again at  
runtime things don't seem at all happy. (In a different way to the  
problems I encountered with the Xcode projects, though - no crazy  
crashes, so far)


For example, trying to view one of the sample data files with  
osgviewer, I get: (with OSG_NOTIFY_LEVEL=DEBUG)


MacPro:Release jmt$ ./osgviewer /Users/jmt/Code/OSG/OpenSceneGraph- 
Data/cow.osg

GraphicsContext::setWindowingSystemInterface() 0x70a5b0 0x620c48
CullSettings::readEnvironmentalVariables()
4 repeats
DriveManipulator::_height set to ==1.5
CullSettings::readEnvironmentalVariables()
9 repeats
itr='/Users/jmt/Library/Application Support/OpenSceneGraph/PlugIns'
FindFileInPath() : trying /Users/jmt/Library/Application Support/ 
OpenSceneGraph/PlugIns/osgPlugins-2.6.0/osgdb_osg.so ...

itr='/Library/Application Support/OpenSceneGraph/PlugIns'
FindFileInPath() : trying /usr/local/lib/osgPlugins-2.6.0/ 
osgdb_osg.so ...

FindFileInPath() : USING /usr/local/lib/osgPlugins-2.6.0/osgdb_osg.so
CullSettings::readEnvironmentalVariables()
CullSettings::readEnvironmentalVariables()
Opened DynamicLibrary osgPlugins-2.6.0/osgdb_osg.so
Warning: Could not find plugin to read objects from file /Users/jmt/ 
Code/OSG/OpenSceneGraph-Data/cow.osg.

./osgviewer: No data loaded

And the same happens with any other example - plugins are found and  
'opened' fine, but that's immediately followed by an error message  
indicating that no suitable plugin could be found.


As far as I know, I've followed the instructions in the README -  
unpack the zip, use the Cmake gui, build with Xcode, install to /usr/ 
local


So I come back to, I must have screwed something up, but I'm unclear  
what.


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

[osg-users] Mac / X-Code build problem

[James Turner]

I'm encountering a bizarre problem with my X-Code build - with (so  
far) 2.5.5 and the 2.6.0-rc2 (will try 2.6.0-final in a moment). I'll  
say right now that I assume it must be a local config problem, I'm not  
trying to blame OSG for the problem (much), just need some help to get  
things working.


Using the supplied X-Code projects, I can build all of OSG just fine.  
It so happens that I'm switching the SDK from 10.4 to 10.5, and I have  
to fix one path in project to build : the osgWidgets path references  
itself via a path that only works in checkout, not a snapshot. Both of  
these things seem pretty minor and unrelated to the problem I'm having.


The problem is, having built **all** of OSG (in either debug or  
release, BTW), nothing works - all the OSG apps launch, but segfault  
within a few seconds - some immediately, some others sort of work  
(osgplanets, untextured) but then crash, others load but the display  
is broken (osgforrest, the tree billboard quads are random colors,  
then it crashes) and so on. The crashes are all very strange - deep  
inside the AGL / CGL code, pthread mutex or condvar internal segfaults  
(loads of these), or just in the guts of the GL driver. Most seem to  
be mangled pointers, but when I look at the OSG objects on the stack,  
they usually look okay - no obvious corruption, though I'm guessing  
what values are sane for the OSG internals.


So, something is obviously very screwed up with my build (or my  
runtime environment). I've built and run countless other GL  
applications with the same tool chain, and I build C++ apps every day  
- I am sceptical that something is seriously wrong with my compiler /  
OpenGL framework / GL driver. Oh, yes, this happens on two different  
machines (both running 10.5 and X-Code 3.0 / 3.1), a MacPro and a  
MacBook Pro.


S - what on earth can be going on? I'm looking forward to testing  
a binary 2.6.0 release, but I'm also mystified. The whole thing feels  
like memory corruption or some hellish threading problem, but I don't  
see why I would be getting those when no one else is.


So, any bright ideas? I'd be happy to have my amazingly dumb mistake  
pointed out.


I suppose I should try a Cmake build of 2.6.0 as well.

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

Re: [osg-users] Mac / X-Code build problem

[James Turner]

On 6 Aug 2008, at 21:57, Eric Sokolowsky wrote:

I can't speak about the Xcode project that comes with OSG, but I  
believe it is no longer actively maintained. While Xcode support is  
still far from perfect within CMake, I have made many recent  
improvements to the CMake build system Xcode generator. Give it a  
try. CMake 2.6 is required, and there is a nice GUI version on the  
CMake downloads page.


It's quite unusual (in an open source project) to discover that  
something isn't actively maintained when it apparently works fine :)  
Of course, it's not 'working fine', but equally, the projects are for  
X-Code 3.0, and give every appearance of building all the code and  
generally functioning. Anyway, thanks for pointing this out. I will go  
and try a CMake build now.


There are several caveats to building OSG on OSX that you should be  
aware of. Read the README.txt file in the base directory of the OSG  
2.6 source code. Feedback is welcome.


I've read the README, it seems pretty clear and as far as I know I'm  
complying with its instructions - but I will double-check.


Thanks,
James

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

[osg-users] osg/GL + glut.h interaction

[James Turner]

Apologies if this is a FAQ or otherwise known, but, the following test  
program fails to compile for me:


=


#include osg/StateSet

#include GLUT/glut.h

#include osg/Drawable

int main(int argc, char** argv)
{
  return 0;
}


=

I'm on Mac, change GLUT/glut.h to GL/glut.h or similar if required.

As it turns out, I don't even want GLUT support in the program I was  
trying to build but there's a genuine issue here - glut.h behaves very  
badly: at its end, it #undef-s APIENTRY.


So when osg/Drawable is included, osg/GL has already been included  
(and guarded against another include, by defining _osg_gl), but  
APIENTRY has been undefined so never gets expanded again - the end  
result is I end up with APIENTRY in the pre-processed source and  
obviously compilation fails.


This took me a while to figure out, so maybe it could be documented?  
But there is an actual (possible) fix - remove the multiple include  
guard  from osg/GL. This should be fine because it's a very small  
file that only consists of pre-processor actions. gl.h would still  
only be pulled in once, but APIENTRY would get set regardless.


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

Re: [osg-users] osg/GL + glut.h interaction

[James Turner]

On 23 Jul 2008, at 10:56, Robert Osfield wrote:


Can you not just avoid GLUT because it's crap for an proper
application development.  Or just put the GLUT include last.  I'm not
going to mess around with the core OSG to make up for deficiencies in
an API that is well passed it's sell by date.


Agreed, but I do think it should be 'officially' documented somewhere,  
because the failure mode is *extremely* confusing. I was dealing with  
code that was indirectly dragging in glut.h through two other layers  
of library headers, and wasted many hours untangling the mess.


Though I suppose the next person to have the issue will search the OSG  
list archives and maybe find this thread. Hello to that person, now  
you know what the fix is :)


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