Re: [osg-users] Problems integrating MFC example with existing application

[Simon Hammett]

2008/9/30 Simon <[EMAIL PROTECTED]>

> Yup, the mfc example is broken.


Doh, ignore me. Just problems with loading plugins, it fails silently...
Mind you the MFC version keeps flashing the screen black when resizing
whilst
the one I wrote which uses setUpViewerAsEmbeddedInWindow doesn't.


>
> If you don't mind it being single threaded, have a look at the osgViewerGtk
> one.
> I adapted that to work with OwlNext2 in about half an hour.
>
> you want something like this:
>
> osgViewer::GraphicsWindow*m_pWindow =
> m_pViewer->setUpViewerAsEmbeddedInWindow(0, 0, rect.right, rect.bottom);
> osgViewer::Viewer*
>  m_pViewer->setThreadingModel(osgViewer::Viewer::SingleThreaded);
>
> then forward window events on using
>
>  void TGlWindow::EvMouseMove(uint /*modKeys*/, TPoint& point)
>  {
> m_pWindow->getEventQueue()->mouseMotion(point.x, point.y);
>  }
>
> Repeat for other windows messages.
>
> Not sure what's wrong with the MFC one at the mo, I was going to start
> poking around
> but then it was the end of the working day! :)
>
> Jesper D. Thomsen wrote:
>
>> Hi again all,
>>  I have an existing MFC application with a window based on Cview, which
>> have been used as an OpenGL rendering canvas. I have now disabled the OpenGL
>> rendering of the window and instead replicated the osgviewermfc example in
>> my application in exactly the same way as in the example.
>>  The problem is that I can't get my model to render, even though the
>> backgroundcolor is defined and rendered by the osg viewer.
>>  When debugging the application I noticed that the
>> viewer-view-_slaves-[0]-_projectionOffset-_mat-[0]...[3]-[0] values change
>> from their initialisation from "addslave" to "-1.#IND000" right
>> after i dispatch the rendering thread. This off course causes further
>> problems in frame() with other values going bad.
>>  My question is whether OSG could be doing this, or if it must be the
>> original application writing somewhere it shouldn't? Or does OSG use som
>> standard OpenGL variables which might be overwritten by the existing
>> application?
>>  Regards, and I know this problem is rightly irritating, but I hope
>> somebody can give me some hints.
>>
>> Jesper D. Thomsen
>>
>> 
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>
>


-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Thread infinite waiting problem

[Simon Hammett]

That's not nearly enough information to enable anyone to help.
Multi threaded apps can hang for any number of reasons.
You'll need to show callstack for each thread and give an other view of you
app design.

2008/10/10 Vincent Bourdier <[EMAIL PROTECTED]>

> Hi all,
>
> Randomly my application freeze. I can have the stack state during the
> freeze, and it seems to be in win32thread.cpp line 645 on
>
> // Wait for the timer.
> if (WaitForSingleObject(sleepTimer.get(), INFINITE) != WAIT_OBJECT_0)
> {
> return -1;
> }
>
> If I am good, the wait() do not stop waiting, and the application stop
> rendering...
>
> This is due to a call at
> microsleep(1)
> in a class which inherit from Switch and OpenThreads::Thread
>
> In the run of this class : it build children (same class) and launch them
> (start() ) or it delete its children, waiting for their thread to be stop
> before deleting themself, if not builting or deleting, it is waiting with a
> simple call to microsleep.
>
> Do you see anything that can make the application wait infinitely ?
>
> thanks.
>
> Regards,
>
>Vincent.
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG MFC Fullscreen

[Simon Hammett]

Try

ChangeDisplaySettingsEx

Not sure how that interacts with MFC though.

2008/11/3 Albino Rodrigues <[EMAIL PROTECTED]>

>  Hi,
>
>
>
> I've created an application based off the OSG MFC example.
>
>
>
> Does anyone know how to swap the rendering context between non full screen
> and full screen (where no GUI is visible)?
>
>
>
> I haven't had much luck researching on MSDN.
>
>
>
> Bino
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] A Windows binary version of OSG 2.6.x available?

[Simon Hammett]

If you want binaries you need to specify which compiler you are using.
I've got 2.7.1 built for vc.Net 2003 but it's a 200Mb zip, without the
examples.
Free to anybody who can provide me somewhere to upload it if anybody else is
using such an old version of vc.

Building yourself is very easy though.

2008/11/6 Holger Krumm <[EMAIL PROTECTED]>

>  Dear all,
>
> I am sincerely looking into this promising API. I want to evaluate the
> loading of VRML files and just wanted to make a quick check.
> On the project's download page I saw a line „Windows pending" for
> the binary package. Because I am not very experienced in that, can
> anybody point me to a download location for the binary package?
> Or can someone provide me with a binary build?
>
> Best regards and thanks for the support here!
>
> Holger
> *___*
>
> *Holger Krumm*
> Product Engineer Test & Experiment Software
> Product Management
>
> dSPACE GmbH  Tel.:  +49 5251 1638-1851
> Technologiepark 25   Fax:   +49 5251 66529
> 33100 Paderborn  *http://www.dspace.de* 
> Germany  *mailto:[EMAIL PROTECTED] <[EMAIL PROTECTED]>
> *___*
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] pragma warnings disabled in headers

[Simon Hammett]

2008/11/7 Robert Osfield <[EMAIL PROTECTED]>

> Hi Peter,
>
> On Fri, Nov 7, 2008 at 12:11 PM, Peter Wraae Marino <[EMAIL PROTECTED]>
> wrote:
> > there is no push/pop for the warning in the header file which will make
> > these warnings disabled in my own code too. I would like to catch this
> > warnings in my own code and I shouldn't be forced to enabling them.
> >
> > the only reason I see for having them grouped here in the header is
> > a convience method so osg doesn't have to disable them all places
> > that gives these warnings? is this correct? or is there a better reason?
>
> The warnings that are disabled are ones that were deemed to be not
> useful and a hindrance to spotting actual useful warnings.  The
> placement in the header is to avoid all OSG code have it's own
> localise pragma - all of which are platform specific.  With the OSG I
> try to keep platform specific hacks self contained rather than
> distributed out across all code.
>
> If you really must have the warnings that perhaps one could add a
> CMake variable for configuring whether to disable these warnings or
> not.  This would need to be a VS specific variable.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>

I agree with Peter, arbitrarily turning off peoples warnings isn't good
practice.
Of course it's the sort of thing people can waste hours arguing about, but
some
of the those warnings are useful if not important:

eg 4996  // 'x': was declared deprecated

If somebody is going to make the effort of deprecating stuff, people should
know about it.

Still there's an easy solution, include the osg headers in your precompiled
header and
surround them with push/pop... Saves mucking around with osgs config.

-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] pragma warnings disabled in headers

[Simon Hammett]

2008/11/7 Robert Osfield <[EMAIL PROTECTED]>

> On Fri, Nov 7, 2008 at 3:42 PM, Simon Hammett
> <[EMAIL PROTECTED]> wrote:
> > I agree with Peter, arbitrarily turning off peoples warnings isn't good
> > practice.
>
> The OSG generally doesn't disable warnings, warning disabling is only
> done on VS as it's had a history of producing lots of warnings on
> correct code.
>
> It's a number of years since I've used Windows.  I do occassionally up
> the warning levels on the OSG via's our Cmake's options for this, this
> can help you spot some useful mistakes, but it also flags lots of
> warnings that mislead more than they inform so you have to enable them
> with an eye to what the warnings really mean - I do occassionally see
> "fixes" to warnings that while well meaning actually break code.
>
> If it's possible to get VS to disable warnings via compiler options
> rather than in source #pragma then this would be the best solution,
> it's what we have under gcc.
>

It is possible to disable via the command line.
I'll have a look into modifying the cmake stuff,
I've got a couple of things to submit as well, so
I'll post to submissions once I'm done.

-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Teaching an intro to graphics course

[Simon Hammett]

For me Geometry handling and generators.

I've spent part of today writing a generalised extrusion function but I'd be
highly
surprised if this hasn't been done 10,000 times already.

I couldn't find such a function in osg.

If it is there, then maybe you could get your students to help with
the documentation in the code and on the website. ;)

Also a high level CSG library would be fantastic.
I'm doing CAD stuff and it would be so much faster if I could just specify
things like 'intersect a cylinder with this box'

This might be relatively straight forward, if the CSG library generates
meshes to feed to:

http://gts.sourceforge.net/


2008/11/7 <[EMAIL PROTECTED]>

> Hello All,
>
> I am going to be teaching my first semester as a part-time adjunct
> professor at BYU-Idaho.  I am really EXCITED!  We will be teaching an intro.
> to graphics course that has not been taught before at this school.  Our
> focus will be on juniors and seniors wanting to get out in the industry and
> do something.
>
> Our thought is to take a direction slightly different from the traditional
> graphics course that works students through writing their own low level
> graphics operations through writing their own phong shader and rudimentary
> ray-tracer.  We know we need to teach the fundamentals with vector and
> matrix math, etc. (a linear algebra class is already set as a
> pre-requisite), but our thought was that we could focus on OpenGL and teach
> how these concepts are important even while working on this relatively high
> level API.
>
> Once we have the fundamentals down and an idea of how OpenGL works, I
> wanted to introduce the students to OSG and how a scene graph helps.
> Another big goal is to teach them how to participate in an Open Source
> community.  Ultimately I would like to have the students work on final
> projects that they might be able to submit to the cause.  There are SOOO
> many great things they could learn from this effort.  I hope we are not
> trying to shove too much into a 3 credit hour class, but I am excited to see
> how it goes.
>
> So, we have a few ideas about the things I think we should cover, but I
> would love to get some feedback from this great community about things that
> you would teach in this kind of course.  I know I want to introduce them to
> the coding standards and the submission guidelines you have on the website.
> Are there other things we should consider on that front?  (should we
> pre-screen the submissions before we send them off to you?).  What kinds of
> projects would you recommend the students might be able to work on?  The LWO
> and LWS readers are near and dear to my heart, so I was going to have them
> work on features there, but I am certainly open to suggestions.
>
> Thanks,
> -- Rick
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] A Windows binary version of OSG 2.6.x available?

[Simon Hammett]

2008/11/7 Robert Osfield <[EMAIL PROTECTED]>

> Hi Simon,
>
> On Thu, Nov 6, 2008 at 1:02 PM, Simon Hammett
> <[EMAIL PROTECTED]> wrote:
> > If you want binaries you need to specify which compiler you are using.
> > I've got 2.7.1 built for vc.Net 2003 but it's a 200Mb zip, without the
> > examples.
> > Free to anybody who can provide me somewhere to upload it if anybody else
> is
> > using such an old version of vc.
>
> You can uploaded data to the server via WebDAV:
>
>   http://www.openscenegraph.org/projects/osg/wiki/WebDAV
>
> If you place the data in the suggested files directory I can move the
> data to downloads directory.
>
> Thanks,
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>

Ok. I've just finished building the libs for VC 2008 as well,
so I'll upload those as well when I've got write access.

-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Teaching an intro to graphics course

[Simon Hammett]

2008/11/7 <[EMAIL PROTECTED]>
>
> Thanks Simon,
>
> A CSG library would be a great idea to work on.  I needed one of those for 
> some work I did with Northrop Grumman.  The generalized extrusion function is 
> cool too, maybe for a single student or as a feature of the CSG library.  I 
> didn't look too deeply, but does the gts library work with OSG?
>
> -- Rick

Err, I don't think so.

I only did a really quick look (read: google search) to see if there
was a suitable library
for my particular needs that would feed OSG, but drew a blank.

Taking the output of GTS and feeding that into OSG is probably trivial,
but I think writing the mesh generators that input to GTS in a nice way,
with good LOD support and decent documentation would be a fair amount of work.

I'm working on a CAD related library for work purposes which has an end
of year deadline, so I can't afford to get bogged down with an immature project.

For my needs I'm just going to write the small sub set of generators
(e.g. cylinder, box, polyline/contour extruder) I need that output
directly into OSG even though
I'm just going to be duplicating stuff that's almost certainly been
done many times before.

>From a style point of few, I'd like to see a CSG library that emulates boost,
more than OSG. OSG needs to support a more restricted compiler environment than
boost aims for; as such it has to avoid the special template tricks
that boost makes
extensive use of.

Mind you a proper boost style template library is probably far beyond
most students.

>From your other email:
> Like I mentioned, I would really like to start off with OpenGL and then show 
> how OSG helps.

Thinking back on my computing related education I think if I wanted to teach
computer graphics myself I would do it the other way round to you.

I would start off by playing TF2 for half an hour with them and
then firing up the source:sdk  and Hammer and showing them the level
design and the
model editors.

Then go back from that to show how OSG can make those things
happen and then tag on a bit of the lower level OpenGL stuff right at the end.

For the really bright students it doesn't matter which way round you do it,
but for the less interested boring them to death with low level details isn't
going to help them. :)

Good luck with the course.

--
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Teaching an intro to graphics course

[Simon Hammett]

I'll have a look this weekend. ty.

2008/11/14 Wang Rui <[EMAIL PROTECTED]>:
> Hi Simon,
>
> As Alberto Luaces said, there is an external library for OSG to support
> various polygon technologies, osgModeling
> (http://code.google.com/p/osgmodeling/) is completely new work and not
> familiar to others. But there have been already Bezier, NURBS, extrusions,
> revolutions (constructed by a profile rotated specified angles) and lofts
> (constructed by lofting a series of curves that define the cross section on
> a specified path) functions, also the boolean operation based on BSP tree of
> geometries.
>
> A future version will conclude the subdivision function (Loop and Sqrt3, and
> easy to add more) and a new NormalVisitor with 6 methods to calculate the
> weights and generate normals. It will be released in 1-2 weeks but you could
> check out the SVN version now.
>
> Hope it will help if you have a similar plan. The project is LGPL and you
> may use it freely, although tons of bugs in it at present. :)
>
> Wang Rui
>

-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] A very simple ref_ptr memory leak example.

[Simon Hammett]

2008/11/18 Chris Denham <[EMAIL PROTECTED]>:
> Thanks for the tips everyone.
> I suppose as Paul suggests, it's best to avoid doing things that hurt.
> The problem is that when we accidentally implemented this pattern in a
> more complex application, it was a bit fiddly to track down. I only
> noticed the problem because of the memory leak that resulted from it.
> I suppose the lesson I learn is that I need to be more careful when
> using ref_ptr than blindly applying it to every Referenced object
> whose lifetime is less than obvious to me. Which I have to confess,
> was my previous rather flawed logic.
> Chris.
>

Don't forget that these reference counted pointers (of all types)
actually conflate two
completely different concepts.

That is:

Ownership - vs - Uses / Has a relationship with

If you break down your use of these pointers into these two concepts
it's usually
easy to work out what to do.

Many objects make use of many different other objects,
but ownership is usually a much more straight forward proposition.

i.e.

It rarely makes sense for object A to own object B and object B to own object A.
but it's quite common for A to use B and B to use A.

In general, use ref_ptr for owner ship and raw pointer (or better yet
references) for uses.

Of course there are exceptions to every rule of thumb, but the only
times I've seen
significant differences are when people are implementing interpreted
languages and
other relatively obscure corner cases.

-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Networking with OSG + Bullet

[Simon Hammett]

There are good articles @ valvesoftware about this:

http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
http://developer.valvesoftware.com/wiki/Lag_Compensation

-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] pragma warnings disabled in headers

[Simon Hammett]

2008/11/21 Wojciech Lewandowski <[EMAIL PROTECTED]>:
> Hi, Guys
> Some middle step solution could be CMake define which would activate warning
> disable in osg\Export. Would this be acceptable ?
>
> What do other OSG windows developers think ?
>

Sounds good to me.
Though perhaps we should go whole hog and make it
so each individual warning can be enabled or disabled.

If you want to post a modified CMakeLists.txt here I'll give it a test.

btw, had you ever noticed the /FI option?
I didn't notice it till I was looking at the warning stuff; could be handy.

-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Very simple Firefox-Plugin to display osg-files

[Simon Hammett]

On windows you can call GetModuleFileName which retrieves the fully
qualified path to the dll/exe
in which the calling function resides.

2008/12/5 Andreas Goebel <[EMAIL PROTECTED]>:
>
>> You will probably have to explicitly provide the library path to go
>> searching for the plugins.  You could either call use the
>> OSG_LIBRARY_PATH env var or set the search path manually via:
>>
>>   osgDB::setLibraryFilePathList(mypath)
>>
>> Or prepend the path to the plugins via:
>>
>>  osgDB::getLibraryFilePathList().push_front(mypath);
>>
>>
>
> I´d sure like to do this, but I can´t figure out the path. I don´t know
> beforehand where Firefox will install the plugin, the path might be
> different on all machines.
>
> I tried various functions, but all only return me the path to the
> firefox-executable, not the plugin-dll.
>
> I consider building a setup with inno-setup, where I can extend PATH.
>
> Any windows-gurus or firefox-gurus that have an idea how I could get the
> path to the plugin?
>
> Regards,
>
> Andreas
>
>> Robert.
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Very simple Firefox-Plugin to display osg-files

[Simon Hammett]

2008/12/5 Andreas Goebel <[EMAIL PROTECTED]>:
> Simon Hammett schrieb:
>>
>> On windows you can call GetModuleFileName which retrieves the fully
>> qualified path to the dll/exe
>> in which the calling function resides.
>>
>
> Sadly no, it returns the path to firefox.exe, already tried that.

The only way I can think of that GetModuleFileName would fail is if
people start moving code around in memory. Seems unlikely firefox
would do that.

Try EnumProcessModules then to get the module handle to your dll.
Then you can use GetModuleFileName with the correct handle.

-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Visual Studio Static compilation

[Simon Hammett]

Why would you want to static link to osg when you say you can have dlls?
Just stick the osg dlls in the same folder as the exe and it should work.

If you really must static link, you can probably just change the project build
type in VS. I haven't tried this though.

Use cmake, set the options, then open the ALL_BUILD.vcproj it will
create in your build directory. Then just go through and change the
'Configure type' property on the 'General' properties page.

I've had issues going from static libs to dlls, but going the other
way should just work.

2008/12/5 Pete Carss <[EMAIL PROTECTED]>:
> Hello All,
>
> For reasons I can't go into without my blood pressure rising, I'm having to
> transfer my development chain from Linux to XP. I wondered if there are any
> Visual Studio gurus on the list that could point me to a source of info on
> static compilation of OSG.
>
> I need to be able to run my OSG based program across a 3 IG cluster - but I
> cannot 'install' my software on the cluster. I need an .exe (and associated
> .dlls - that be run happily from a folder. I can change the path on the
> machines in the cluster
>
>
> Pete
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Very simple Firefox-Plugin to display osg-files

[Simon Hammett]

2008/12/5 Andreas Goebel <[EMAIL PROTECTED]>:
> Simon Hammett schrieb:
>>
>> 2008/12/5 Andreas Goebel <[EMAIL PROTECTED]>:
>>
>>>
>>> Simon Hammett schrieb:
>>>
>>>>
>>>> On windows you can call GetModuleFileName which retrieves the fully
>>>> qualified path to the dll/exe
>>>> in which the calling function resides.
>>>>
>>>>
>>>
>>> Sadly no, it returns the path to firefox.exe, already tried that.
>>>
>>
>> The only way I can think of that GetModuleFileName would fail is if
>> people start moving code around in memory. Seems unlikely firefox
>> would do that.
>>
>> Try EnumProcessModules then to get the module handle to your dll.
>> Then you can use GetModuleFileName with the correct handle.
>>
>>
>
> I´ll have to stop working on that till tonight. Maybe you could give me a
> code-snippet, I am no expert-windows-api-programmer, I prefer using
> wxWidgets.
>

http://msdn.microsoft.com/en-us/library/ms682631(VS.85).aspx

That's the doc for the function and there is example code linked to as well.

If you ever need info for windows programming, always check out msdn.
Not a big fan of MS, but their documentation is usually pretty good;
once you can work out what they've called the feature you are
interested in is called anyway.

-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Very simple Firefox-Plugin to display osg-files

[Simon Hammett]

> It does not fail, but his plugin source code does not know it's instance
> handle, because DllMain() is deeply buried in the Plugin API, I guess.
>

If you pass a null handle to GetModuleFileName it uses the return address
on the stack to work out which dll the calling function is in.
It should always work for any function linked in an exe or dll.

Not sure what it does if you generated code in memory though,
maybe it just gives up and decides you mean the exe.

-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Very simple Firefox-Plugin to display osg-files

[Simon Hammett]

2008/12/5 Ralph Kern <[EMAIL PROTECTED]>:
> Simon Hammett schrieb:
>> If you pass a null handle to GetModuleFileName it uses the return address
>> on the stack to work out which dll the calling function is in.
>> It should always work for any function linked in an exe or dll.
>>
>
> Sorry, Simon, you are wrong:
>
> Quote from MSDN GetModuleFileName():
> http://msdn.microsoft.com/en-us/library/ms683199(VS.85).aspx
>> If this parameter is NULL, GetModuleHandle returns a handle to the file used 
>> to create the calling process (.exe file).
>
> If you pass NULL, it refers to the .exe (firefox.exe), not to the DLL on
> the stack.
>
> regards Ralph

Nuts, I must be confusing it with one of the debug help functions.
Easiest way is to do it DllMain then, you get passed the handle to your dll.
Then just store the handle or the path.

-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Very simple Firefox-Plugin to display osg-files

[Simon Hammett]

>
> Nuts, I must be confusing it with one of the debug help functions.
> Easiest way is to do it DllMain then, you get passed the handle to your dll.
> Then just store the handle or the path.
>

Knew there was a relatively straight forward way of doing it:

wchar_t buff[256];

buff[0] = '\0';

HMODULE  module;

if( TRUE == GetModuleHandleEx(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS,
reinterpret_cast< LPCWSTR >(&DllMain), &module) )
  GetModuleFileName(module, buff, 256);

You need _WIN32_WINNT as 0x0501 or later though

-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] 4m 36 seconds!

[Simon Hammett]

2008/12/5 Robert Osfield <[EMAIL PROTECTED]>:
> Hi All,
>
> I've taken a picture of my latest computer jut to make you all jealous :-)
>
> Robert.
>

Brilliant! That looks like how my machine performs.
-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenVRML and Windows

[Simon Hammett]

2008/12/5 Serge Lages <[EMAIL PROTECTED]>:
> I tried the patch but it doesn't work for Visual Studio.
>
> Anyone have an idea on how to transform a method declaration like that :
>
> float (&operator[](size_t index) throw ())[4];
>
> In something similar but VS compliant ?
>

If you are trying to get a pointer to member function you need the
class name in front of operator eg

float (&AClass::operator[](size_t index) throw())[4];

VC7.1 compiles that, but later versions are more standards compliant.

-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] The build of osg2.6 succeed in my computer but failed in another!

[Simon Hammett]

The VS linker does go nuts on rare occasions.
This happens more often when using Incremental linking, so you might
try turning that off.
Just do the osg project only first to see if that fixes it.

2008/12/8 xuhuabing <[EMAIL PROTECTED]>:
> Hello
> I am a user of OpenSceneGraph-2.6.0, I download the source package and
> compiled it with vs2003, it succeed in my computer, however, it failed in
> another computer, the problem is the link error in the core osg vcproject.
> The memory usage increased all the time, then the computer collapse for
> deficiency of memory. I want to know if there is similar problem existed!
> And how to solve it! Thanks!
>
> 2008-12-08
> 
> xuhuabing
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>



-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Is it time that we have a OpenSceneGraph/src/3rdPartyPlugins directory?

[Simon Hammett]

2008/12/9 Robert Osfield <[EMAIL PROTECTED]>:
> Hi All,
>

Snip.

>
> Thoughts? Recommendations?
> Robert.
> ___
> osg-users mailing list

Well I'm not too keen on having loads of third part stuff in the default core.
Building osg is already painfully slow, the only machines I have
access to are over 3 years old...

If you can download them separately and unpack them in there when you want them
it's not to bad, but I don't think that fits in with the way SVN works does it?

-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Is it time that we have a OpenSceneGraph/src/3rdPartyPlugins directory?

[Simon Hammett]

2008/12/9 Robert Osfield <[EMAIL PROTECTED]>:
> HI Simon,
>
> On Tue, Dec 9, 2008 at 3:30 PM, Simon Hammett
> <[EMAIL PROTECTED]> wrote:
>> Well I'm not too keen on having loads of third part stuff in the default 
>> core.
>> Building osg is already painfully slow, the only machines I have
>> access to are over 3 years old...
>
> The CMake build system only compiles that components you have
> dependencies for, and you select building of components as well.  If
> we do add extra 3rd party plugins it shouldn't make any different to
> your build times, unless you require these plugins.
>
> Speeding up the OSG build is separate topic, so I won't dive in to
> suggestions on this thread.  You're welcome to start a new thread on
> this topic to so what others might recommend to helping cut your
> compile times.
>
> Robert.

True enough, but I am only building the core of osg and the default plugins.
None of the other components build as I don't configure them and I'm unlikely
to ever use them. I'm not going to be using any of
osgParticle/osgTerrain/osgWidget
in the foreseeable future either (worse luck)

If there are another bunch of core libs, eg. osgWidget I have to remember to
disable them in cmake or they build as well. It's not too bad at the moment,
but if we wind up with lots of 3rd party libs the cmake interface is a pain.

But it also seems silly to have a core library which doesn't build by default,
or you wonder why it's there.

Unfortunately we 'doze uses have to build the debug and release builds so
it all adds up.

Perhaps the cmake could be split in 2, so there's one for the core (and a couple
of examples) and another for the extras? That would work with visual studio
projects but I don't know if that would work with linux build systems...

That would be handy as people new to osg could get up and running faster
and you've still got all the goodies to play with later.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Is it time that we have aOpenSceneGraph/src/3rdPartyPlugins directory?

[Simon Hammett]

> It should be possible to achieve these same benefits with one CMake system.
>   -Paul

I was thinking about 2 separate ones due to way the UI tool works on windows.
You just get a big long list of options, with a bunch hidden behind an
'Advanced'
checkbox.

So you have carefully review every line, hit configure and then yet
more options appear.
It's nicer than make files, but it's not the last word in ease of use.
It's very easy to miss an option.

If there is a way to just group things more nicely then one cmake
would be better.

-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Cmake question - is it possible to explicitly pull in symbols in a static lib?

[Simon Hammett]

> Is this idea possible with compilers?  Is it possible with CMake?
>

VS has a force include symbol option, which looks like it will make
the linker pull in a library:

> The /INCLUDE option tells the linker to add a specified symbol to the symbol 
> table.
> The linker resolves symbol by adding the object that contains the symbol 
> definition
> to the program. This feature is useful for including a library object that 
> otherwise would
> not be linked to the program.

I've not used it myself though.

-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Windows XP GDI Menu Shadow flicker on ATI Radeon

[Simon Hammett]

No it's not multi threading. My single threaded non OSG apps do the same,
and that's with my OpenGl rendering code called in response to WM_PAINT.

It's something to do with the back buffer swap overwriting the screen
without being properly synchronised with GDI but I've never had time to
investigate it properly.

I think you might have to render to a buffer and then copy it across
in response to WM_ERASEBKGND to play nicely with GDI but I've
not tried doing that yet.

2008/12/15 Schmidt, Richard :
> Hi,
> we are having the same issues here and I think the problem is related to
> multithreading.
>
> One solution may be to sync your drawing thread to the drawing of
> windows or to sync the swap operation in double buffered mode.
>
> I don't know if that helps, it's just a guess.
>
> Richard

-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Windows XP GDI Menu Shadow flicker on ATI Radeon

[Simon Hammett]

Robert is quite correct; it's nothing to do with OSG.
(nor your driver version)

My raw OpenGl programs have the same problem
and so do quite a few other none OSG programs.

I've never been bothered enough to investigate myself though.
A quick & dirty solution is just to disable screen updates when a menu
is opened.

2008/12/15 Robert Osfield :
> Hi Eron,
>
> The best I can recommend is try updating your OpenGL driver.  Updating
> to the lastest OSG is very unlikely to help with this particular
> issue, but it may well be worth doing for all the other fruity
> goodness that it delivers ;-)


-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Windows XP GDI Menu Shadow flicker on ATI Radeon

[Simon Hammett]

Curious. Could you provide a really stripped down program which
doesn't have dodgy menus? mfc / atl or raw win32, as I don't have
any other GUI toolkits setup.

I can make one out of my programs but you've already looked
at one wrong program so another wrong one isn't going to help...

2008/12/15 Eron Steger :
> I have other raw OpenGL programs that do not exhibit this problem.  I figure
> it has something to do with either how OSG sets up the window, the wgl
> context, or how drawing is performed.  Unfortunately, I haven't been able to
> identify what is causing the problem.
>
> - Eron

-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Memory management in OSG

[Simon Hammett]

2008/12/19 Pierre Bourdin (gmail) :
> Hi,
> valgrind is very powerfull if you're on an Linux/Unix environnement, if you
> are using MSVC you can use this:
>
> add this bloc at the beginning of each file you want to trace (after all
> includes):
> #ifdef _WIN32
> # ifdef _MSC_VER
> # ifdef _DEBUG
> # include 
> # undef THIS_FILE
> static char THIS_FILE[] = __FILE__;
> # define malloc(s) _malloc_dbg(s, _NORMAL_BLOCK, __FILE__, __LINE__)
> # define calloc(s) _calloc_dbg(s, _NORMAL_BLOCK, __FILE__, __LINE__)
> # define realloc(s) _recalloc_dbg(s, _NORMAL_BLOCK, __FILE__, __LINE__)
> # define new new(_NORMAL_BLOCK, __FILE__, __LINE__)
> # define delete delete(_NORMAL_BLOCK, __FILE__, __LINE__)
> # endif /* _DEBUG */
> # endif /* _MSC_VER */
> #endif /* _WIN32 */
>

Doesn't crtDbg.h do what you want?

#define _CRTDBG_MAP_ALLOC
#define _CRTDBG_MAP_ALLOC_NEW
#include 

-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] computeIntersections problem

[Simon Hammett]

It's not the functions you are calling, you are incorrectly mixing
different C runtime libraries.

When you are using windows, you must use debug builds of OSG with your
debug build application.
And release builds with release.

If you mix the 2 then objects get allocated from different heaps and
bad things happen.

The debug builds of OSG have the letter d appended to them.
Check the settings in one of the example projects if you are not sure
what to do.

2008/12/23 Francesco Argese :
> Hi all,
>
> i'm trying to implement PickHandler in my application with osg 1.2.
> Following example osg::pick i have written the following lines of
> code:
>
> bool PickHandler::pick (const double x, const double y,
> osgProducer::Viewer* viewer)
> {
> std::vector hlist;
> if ( viewer->computeIntersections(x, y, hlist) )
> {
>   //Here i handle the information recovered from computeIntersections()
>hlist.clear();
> }
> return true;
> }
>
> Im working under Windows: the resulting application works well if i
> compile it in release mode but when use in debug mode it give me the
> following error on instruction hlist.clear(). If i don't call this
> instruction it give me the same error at the return (because the
> application try to empty Heap).
>
> Debug Assertion Failed
> File:dbddel.cpp
> Line:52
>
> Exception: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse).
>
> I have tried to comment the code containing computeIntersection and
> all works well. It seems that computeIntersections function do
> something on hlist, avoiding to empty memory.
>
> How can i resolve this problem? Does exist another functionto to have
> the same behaviour? How can i try to resolve this problem?
>
> Thanke in advance
> Francesco Argese
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Building VPB on Windows

[Simon Hammett]

Well it's hard to give you any pointers if you don't supply the error
messages...

2008/12/23 Michael W. Hall :
> I just ran the configure utility.  I am getting errors with CMake
> configure.  Reports that a lot of the variables are set to not found.
>
> Windows XP BTW and Visual Studio 2005.
>
> Michael
>
> On Tue, 2008-12-23 at 15:33 -0600, Michael W. Hall wrote:
>> I am trying to build VPB on my Windows machine.  I get about 64 errors.
>> I got the 2.6 version of OSG and I got the latest VPB from SVN.  This
>> could be my problem.
>>
>> I created all the Environment variables (i.e. OSG_ROOT, OSG_BIN_PATH,
>> etc).  When I tried a rebuild, it failed with the same errors.  Could
>> someone put me on track?
>>
>> Thanks,
>> Michael
>>
>> ___
>> 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
>



-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Node Names After Picking

[Simon Hammett]

2009/1/2 Ryan Morris :
> Just to be clear, would something like:
>
> osg::Node *node = osgDB::readNodeFile("file.osg");
> osg::Geode *geode = osg::dynamic_castnode;
>
> geode->getDrawable()->setName("New name");
>
> should work? (syntax might be a little off I'm not at my home system right 
> now).
>

Well it will work if the root of the scene is a geode,
which is extremely unlikely for any non-trivial scene graph.

It's much more likely that the root will be a class which derives
from osg::Group

-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Node Names After Picking

[Simon Hammett]

2009/1/3 Simon Hammett :
> 2009/1/2 Ryan Morris :
>> Just to be clear, would something like:
>>
>> osg::Node *node = osgDB::readNodeFile("file.osg");
>> osg::Geode *geode = osg::dynamic_castnode;
>>
>> geode->getDrawable()->setName("New name");
>>
>> should work? (syntax might be a little off I'm not at my home system right 
>> now).
>>
>
> Well it will work if the root of the scene is a geode,
> which is extremely unlikely for any non-trivial scene graph.
>
> It's much more likely that the root will be a class which derives
> from osg::Group
>

Doh. Should be:

geode->getDrawable( 0 )->setName("New name");

Or better yet:

for(unsigned i = 0, iC = geode->getNumDrawables(); i != iC; ++i )
geode->getDrawable( i )->setName( GenerateName( i ) );

-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] MFC SDI Example

[Simon Hammett]

The MDI mfc version has the same problems last time I tried it.

Try calling setUpViewerAsEmbeddedInWindow on your viewer.
If you problems go away you're hitting threading issues.

2009/1/8 Brad Huber :
> Umit,
>
>
>
> Thanks.  The SDI application that I have created so far is very simple and
> does nothing more than what the MDI example app does.  As far as I can tell
> there is no difference in the way the example creates/uses/deletes the cOSG
> object and the way I am doing it, yet I get assertions or exceptions on
> exit.
>
>
>
> Anyone else?
>
>
>
> Thanks
>
> -Brad
>
>
>
> From: osg-users-boun...@lists.openscenegraph.org
> [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun
> Sent: Thursday, January 08, 2009 2:08 PM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] MFC SDI Example
>
>
>
> Hi Brad,
>
> I created SDI MFC project in OSG. But this was commercial and complicated to
> understand you very well. Because it was SDI dll to call from anywhere you
> need and you then delete it if you don't need to much.
>
> I haven't understood the assertion faults very well but you should only
> understand the cOSG class creation style. You will use it in your SDI
> project and be careful to delete everything while you are destroying your
> dialog. And be careful about the threads sleeping time to be activeted.
> Because sometimes sleeping times can't be enough to be threads get
> activated, so it may create assertion fault as you say.
>
> Hope this helps. Regards.
>
> 2009/1/8 Brad Huber 
>
> Hello all,
>
>
>
> Does anyone know where one might find an example project of using
> MFC/OSG/SDI?
>
>
>
> If anyone has one sitting around on their machine I would be interested if
> you can email it to me as well.
>
>
>
> I've already tried adapting the MFC MDI example to an SDI project but I seem
> to be hitting some snags where the app won't exit properly.
>
>
>
> It either asserts the window as being still valid when it shouldn't be
> [CWnd::WalkPreTranslateTree's ASSERT(hWndStop == NULL ||
> ::IsWindow(hWndStop))] or it get's "The activation context being deactivated
> is not the most recently activated one" exception within osg53-osgGAd.dll
> after I've deleted all osg items.
>
>
>
> I'm a little bit baffled why I'm getting this.
>
>
>
> Anyway does anyone have any SDI examples?
>
>
>
> Thanks
>
> -Brad
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
> --
> Ümit Uzun
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>



-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] package names for static builds ?

[Simon Hammett]

2009/1/14 Jean-Sébastien Guay :
> Hi Mattias,
>
>> 1. When building static libraries - should we indicate this in the
>> package filename? e.g.
>> libopenscenegraph-dev-2.x.y-win32-x86-vc80-Release-static.tar.gz ?
>
> I would say yes, otherwise how do we separate the static and dynamic builds?
>
>> 2. For msvc OsgCPack.cmake detect the compiler (and service pack if
>> vc80). Is the compiler and it's version important to have in the
>> package name for any other platform than windows?
>
> I'm not an expert, but I think it's important when linking to libraries that
> they use the same libc version? Is that right? If so, and I think there is a
> correspondence between the gcc version and the libc version, then it might
> be useful to include the gcc version on Linux. Other platforms might have
> similar arguments.
>
> But others will probably be better placed to answer this.
>
> Thanks again for your continued work on this.

Sometimes the ABI will change between major compiler revisions, so you need to
indicate that in the package name.

For Visual studio, the libraries are incompatible 6,7 & 8.
I think the same thing happened with Gcc between 3 & 4 as well.

-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] LWO loading problem

[Simon Hammett]

Works ok in 2.7.1.

2009/2/5 Csaba Halász :
> Hi everybody.
>
> I have gotten a report that the LWO loader doesn't seem to work.
> Investigating, I grabbed the sample LWO file posted by Marco Jez back
> in november last year (attached for convenience).
> Loading into osgviewer, I get an empty view. Trying osgconv, I get an
> osg file full of zeroes and nans (also attached).
> With SIGFPE enabled, gdb shows:
>
> Program received signal SIGFPE, Arithmetic exception.
> [Switching to Thread 0x7f9b6be43730 (LWP 10599)]
> 0x7f9b6756e456 in lwosg::Block::setup_texture_point
> (this=0xaee3c8, p...@0x7fff73fdcca0) at
> OpenSceneGraph/src/osgPlugins/lwo/Block.cpp:141
> 141 Q.x() *= 1/imap_.mapping.size_.x();
> Current language:  auto; currently c++
> (gdb) p imap_.mapping
> $1 = {center_ = {_v = {0, 0, 0}}, size_ = {_v = {0, 0, 0}}, rotation_
> = {_v = {0, 0, 0}},
>  csys_ = lwosg::Texture_mapping::OBJECT}
>
> That's clearly the source of the nans but maybe not the root of the problem.
> I haven't tried to find the exact svn rev this got broken yet, maybe
> somebody has a quick solution right away.
>
> --
> Thanks,
> Csaba
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>



-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] build on windows

[Simon Hammett]

That's a header from mfc/atl which you won't have unless you have the
full version of visual studio.
You can try just editing the OpenThreadsVersionInfo.rc by hand and
commenting out that include.
It doesn't look like the rc is using any of the mfc defines.

2009/2/10 Cedric Pinson :
> Hi Robert and all,
>
> i just tried to update my application on windows and now i have this error:
>
> Build started 2/10/2009 4:05:58 AM.
> Project "c:\sources\osg-branch\openscenegraph.sln" on node 0 (build
> target(s)).
>  Building solution configuration "Release|Win32".
> ..\..\..\PlatformSpecifics\Windows\OpenThreadsVersionInfo.rc(9): fatal error
> RC
> 1015: cannot open include file 'afxres.h'.
>
> before i did not have afxres.h can. I will check if there is an option to
> disable this behaviour
>
> Cheers,
> Cedric
>
> --
> +33 (0) 6 63 20 03 56  Cedric Pinson mailto:morni...@plopbyte.net
> http://www.plopbyte.net
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] ComputeBoundsVisitor problem

[Simon Hammett]

ComputeBoundsVisitor only computes bounds for drawables. ie geometry.

2009/2/11 Engvall Åsa :
> Hi osg-users!
>
> I want to use a ComputeBoundsVisitor for finding the bounds of an object.
> The object belongs to the class GroundObject, which is derived from
> osg::Node.
>
> Please have a look at this short function. The visitor is probably not
> executed, and the resulting bounding box is not valid.
>
> void GroundObject::calculateDistanceToGround(void)
> {
> // Calculate distance from local origin to ground.
> osg::ComputeBoundsVisitor cbv;
> accept(cbv);
> osg::BoundingBox box = cbv.getBoundingBox();
> if (!box.valid()) ssPrintf("Bounding box is not valid!\n");
> _distanceToGround = osg::absolute(box.zMin());
> }
>
> What is wrong here?
> Thanks in advance,
>
> Åsa Engvall
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>



-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] ComputeBoundsVisitor problem

[Simon Hammett]

I take it GroundObject is your own class that acts as a container.
Have you implemented the traverse method?

2009/2/11 Engvall Åsa :
> Yes, but I was expecting that the visitor should traverse the graph an find 
> the geometry that is below the GroundObject. If I do the same thing on an 
> osg::Node, it works. Both the Node and the GroundObject are created using 
> readNodeFile.
>
> Åsa
>
> -Ursprungligt meddelande-
> Från: osg-users-boun...@lists.openscenegraph.org 
> [mailto:osg-users-boun...@lists.openscenegraph.org] För Simon Hammett
> Skickat: den 11 februari 2009 12:51
> Till: OpenSceneGraph Users
> Ämne: Re: [osg-users] ComputeBoundsVisitor problem
>
> ComputeBoundsVisitor only computes bounds for drawables. ie geometry.
>
> 2009/2/11 Engvall Åsa :
>> Hi osg-users!
>>
>> I want to use a ComputeBoundsVisitor for finding the bounds of an object.
>> The object belongs to the class GroundObject, which is derived from
>> osg::Node.
>>
>> Please have a look at this short function. The visitor is probably not
>> executed, and the resulting bounding box is not valid.
>>
>> void GroundObject::calculateDistanceToGround(void)
>> {
>> // Calculate distance from local origin to ground.
>> osg::ComputeBoundsVisitor cbv;
>> accept(cbv);
>> osg::BoundingBox box = cbv.getBoundingBox();
>> if (!box.valid()) ssPrintf("Bounding box is not valid!\n");
>> _distanceToGround = osg::absolute(box.zMin()); }
>>
>> What is wrong here?
>> Thanks in advance,
>>
>> Åsa Engvall
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.
>> org
>>
>>
>
>
>
> --
> The truth is out there. Usually in header files.
> ___
> 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
>



-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] DrawArrays and bind_per_primitive

[Simon Hammett]

No it works fine for me. (2.7.1)
It doesn't work with tri/quad strips though, you get the same behavior
as BIND_OVERALL.

2009/2/20 Steven Saunderson :
> Is BIND_PER_PRIMITIVE allowed when using a DrawArrays (GL_QUADS) primitive ?  
> I've found that if I do this and save the scene as an .osg file it will crash 
> osgviewer.  If I save the scene as an .ive file then there is no problem.
>
> I chose BIND_PER_PRIMITIVE here because it seems sufficient and avoids 
> duplication of identical normals.
>
> Thanks,
>
> 
> -- Steven Saunderson
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=7104#7104
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] photos to be displayed in sequence

[Simon Hammett]

So you need @ minimum168 Mb/sec streaming bandwidth from your hard discs

That's not utterly insane, but many older PC's won't be able to
deliver that sort of bandwidth.

On my current machine the burst transfer rate from cache (ie memory to
memory copy)
is only 184 Mb/sec.

Reading from HD I only get 60 Mb/sec at peak so I couldn't run
your program smoothly even if you haven't made any mistakes...

If you want your program to work on anything other than very high end machines,
you are going to have to change to a compressed image format.

2009/3/5 salvatore :
> hello Robert,
> I have 40,000 photos in tga format with 1400x1050 definition and a frame rate 
> of 30 fps, the load in this way:
>
> imageSequence-> addImage (osgDB:: readImageFile 
> ("hh3fcenter/immage_.tga"));
>
> in the various attempts I have tried with 240 photos and goes very badly, I 
> thought to pack 30 photos in a knot so as to obtain the nodes that represent 
> a second, but I do not know how to play these nodes so that the sequence is 
> continuous,
> thanks in advance
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=8013#8013
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] background color fills all the window (not only the given viewport)

[Simon Hammett]

This might be want you are looking for:

http://factor-language.blogspot.com/2007_08_01_archive.html

and

http://factor-language.blogspot.com/2007/08/opengl-redraw-bug-on-windows.html

Basically enable the scissor test, then tell OpenGl what part of the
window to update when calling SwapBuffers.

Not tried it myself though.

2009/3/26 Guy :
> Frederic,
>  I think you can't limit the OpenGL drawing to a limited region of a window 
> HANDLE. You could embed a window in the region you want to use OGL, and just 
> draw to it. Or you could first draw the OGL/OSG code, and then get the window 
> handle and draw all your other stuff using GDI or whatever.
>
> Guy.
>
> -
>
>
> hum, the (black) color was not the problem in itself :)
>
> If I do this (update from my whole code):
>        gc->setClearColor( osg::Vec4f(1.2f, 0.2f, 0.6f, 1.0f) );
>        gc->setClearMask( 0) ;
>
>        camera->setClearColor( osg::Vec4f(0.2f, 0.2f, 1.6f, 1.0f) );
>        camera->setClearMask( GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT );
> (that's to say: don't clear anything on gc, and fill background with
> blue on camera),
>
> I have the camera successfully drawn at the right place, with blue
> background. This is what I want for that camera.
> BUT, the problem persists, i.e. all around the viewport, the whole
> window is painted in black. (maybe mick jagger is singing too loud ?).
> it is painted in pink if I enable the gc->setClearMask(GL_COLOR_BUFFER_BIT).
>
> I can't manage to make OSG only impact the camera viewport (my blue
> rectangle) and leave the window around unchanged...
> Did anyone achieve to display an osgViewer::Viewer at some small place
> in a window without overwrite window content around?
>
> Fred
>
>
>
> 2009/3/25 Robert Osfield :
>> On Wed, Mar 25, 2009 at 3:03 PM, Frederic Marmond 
>> wrote:
>>>
>>> hum, it didn't work :(
>>>
>>> both
>>> //      gc->setClearColor( osg::Vec4f(1.2f, 0.2f, 0.6f, 1.0f) );
>>> //      gc->setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );
>>> and
>>>        gc->setClearColor( osg::Vec4f(1.2f, 0.2f, 0.6f, 1.0f) );
>>>        gc->setClearMask( 0 );
>>>
>>> do the same: instead of the shiny pink color, the window is filled with
>>> black
>>>
>>> any other suggestion ?
>>
>> Well you disable the clear colour in the camera's ClearMask so perhaps this
>> is why it's just black.
>>
>> Robert.
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] background color fills all the window (not only the given viewport)

[Simon Hammett]

Yes I know.

The magic is in the use of glAddSwapHintRectWIN which is a wgl function.

I've just tested this and it works, so you can update part of the window using
plain GDI calls and do the rest with opengl.

Mind you I wouldn't trust it work on all machines.
It's probably less of head ache to just use separate windows...

2009/3/26 Robert Osfield :
> HI Simon,
>
> I'm afraid the OSG already uses the sissor test to make sure that the
> viewport clear only affects the region of interest.  It work, but the
> problem Fredric has really all about the fact that the OpenGL context
> affects the whole window it's assigned to.
>
> Robert.
>
> On Thu, Mar 26, 2009 at 8:59 AM, Simon Hammett 
> wrote:
>>
>> This might be want you are looking for:
>>
>> http://factor-language.blogspot.com/2007_08_01_archive.html
>>
>> and
>>
>>
>> http://factor-language.blogspot.com/2007/08/opengl-redraw-bug-on-windows.html
>>
>> Basically enable the scissor test, then tell OpenGl what part of the
>> window to update when calling SwapBuffers.
>>
>> Not tried it myself though.
>>
>> 2009/3/26 Guy :
>> > Frederic,
>> >  I think you can't limit the OpenGL drawing to a limited region of a
>> > window HANDLE. You could embed a window in the region you want to use OGL,
>> > and just draw to it. Or you could first draw the OGL/OSG code, and then get
>> > the window handle and draw all your other stuff using GDI or whatever.
>> >
>> > Guy.
>> >
>> > -
>> >
>> >
>> > hum, the (black) color was not the problem in itself :)
>> >
>> > If I do this (update from my whole code):
>> >        gc->setClearColor( osg::Vec4f(1.2f, 0.2f, 0.6f, 1.0f) );
>> >        gc->setClearMask( 0) ;
>> >
>> >        camera->setClearColor( osg::Vec4f(0.2f, 0.2f, 1.6f, 1.0f) );
>> >        camera->setClearMask( GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT
>> > );
>> > (that's to say: don't clear anything on gc, and fill background with
>> > blue on camera),
>> >
>> > I have the camera successfully drawn at the right place, with blue
>> > background. This is what I want for that camera.
>> > BUT, the problem persists, i.e. all around the viewport, the whole
>> > window is painted in black. (maybe mick jagger is singing too loud ?).
>> > it is painted in pink if I enable the
>> > gc->setClearMask(GL_COLOR_BUFFER_BIT).
>> >
>> > I can't manage to make OSG only impact the camera viewport (my blue
>> > rectangle) and leave the window around unchanged...
>> > Did anyone achieve to display an osgViewer::Viewer at some small place
>> > in a window without overwrite window content around?
>> >
>> > Fred
>> >
>> >
>> >
>> > 2009/3/25 Robert Osfield :
>> >> On Wed, Mar 25, 2009 at 3:03 PM, Frederic Marmond 
>> >> wrote:
>> >>>
>> >>> hum, it didn't work :(
>> >>>
>> >>> both
>> >>> //      gc->setClearColor( osg::Vec4f(1.2f, 0.2f, 0.6f, 1.0f) );
>> >>> //      gc->setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );
>> >>> and
>> >>>        gc->setClearColor( osg::Vec4f(1.2f, 0.2f, 0.6f, 1.0f) );
>> >>>        gc->setClearMask( 0 );
>> >>>
>> >>> do the same: instead of the shiny pink color, the window is filled
>> >>> with
>> >>> black
>> >>>
>> >>> any other suggestion ?
>> >>
>> >> Well you disable the clear colour in the camera's ClearMask so perhaps
>> >> this
>> >> is why it's just black.
>> >>
>> >> Robert.
>> >>
>> >> ___
>> >> osg-users mailing list
>> >> osg-users@lists.openscenegraph.org
>> >>
>> >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>> >>
>> >>
>> > ___
>> > osg-users mailing list
>> > osg-users@lists.openscenegraph.org
>> >
>> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>> > ___
>> > osg-users mailing list
>> > osg-users@lists.openscenegraph.org
>> >
>> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>> >
>>
>>
>>
>> --
>> http://www.ssTk.co.uk
>> ___
>> 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
>
>



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

Re: [osg-users] how to set osg::notify to a file

[Simon Hammett]

This works for me:

#include 
#include 

static std::ofstreamg_log("c:\\Message.log");

extern "C" int WINAPI _tWinMain(HINSTANCE /*hInstance*/, HINSTANCE
/*hPrevInstance*/, LPTSTR /*lpCmdLine*/, int nShowCmd)
{
   std::cout.rdbuf(g_log.rdbuf());
   std::cerr.rdbuf(g_log.rdbuf());
   ...
   ...
}

There's a version that outputs to the debug window in visual studio on
the osg website and in the mail achieves if that's your preference.

2009/5/11 Vincent Bourdier :
> Hi,
>
> Using the std stream, you can redirect the out stream into a file stream.
> I don't know if osg implements a thing about that, i think it don't...
>
> Regards,
>    Vincent
>
> 2009/5/11 forest 
>>
>> hi all
>>    osg::notify put notifies on the console defaultly.Can I put these
>> notifies to a file?
>>    thanks in advance.
>>    best regardes
>> forest
>> ___
>> 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
>
>

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

Re: [osg-users] Repost: Top 10 debugging tips

[Simon Hammett]

Many, (most?) osg users are using windozes.
So redirecting osg::notify messages should be in that list.

(Plz somebody give me a job developing for *ix.!)

2009/5/12 Paul Martz :
> I've created the following list of debugging tips to help new OSG developers
> become productive faster:
>   http://www.skew-matrix.com/bb/viewtopic.php?f=6&t=5
>
> I hope you find it useful. Feedback appreciated.
>
> Paul Martz
> Skew Matrix Software LLC
> http://www.skew-matrix.com
> +1 303 859 9466
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>



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

[osg-users] Camera view frustum to Polytope

[Simon Hammett]

Hi Everyone,

Is there a quick and easy way to populate a osg::Polytope with a
cameras view frustum?
I've tried stepping though osg::Viewer::frame(), but there's so much
code I've either
not stepped into the right function or just missed it and searching
the mail achieve just
brings up too many false results.

tia, Simon.

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

Re: [osg-users] Camera view frustum to Polytope

[Simon Hammett]

Thanks Robert :)

Put me on the right track. Just for reference if anybody else needs it:

osg::Polytope  frustum;

frustum.setToUnitFrustum();
frustum.transformProvidingInverse(
pViewer->getCameraManipulator()->getInverseMatrix() *
pViewer->getCamera()->getProjectionMatrix());


2009/5/14 Robert Osfield :
> Hi Simon,
>
> What you need to do is use the Polytope::setToUnitFrustum(..) method
> to create the eye space -1,1 unit cube, then transform this is to
> world coordinates by multiplying it by the inverse of the camera's
> view matrix.  It just so happens that there is a
> Polytope::transformProvidingInverse() method which you use (planes are
> transformed by multiplying by their inverse).
>
>  Polytope frustum;
>  frustum.setToUnitFrusmtum();
>  frustum.transformProvididingInvser(camera.getViewMatrix());
>
> Robert.
>
>
>
>
> On Wed, May 13, 2009 at 9:20 PM, Simon Hammett
>  wrote:
>> Hi Everyone,
>>
>> Is there a quick and easy way to populate a osg::Polytope with a
>> cameras view frustum?
>> I've tried stepping though osg::Viewer::frame(), but there's so much
>> code I've either
>> not stepped into the right function or just missed it and searching
>> the mail achieve just
>> brings up too many false results.
>>
>> tia, Simon.
>>
>> --
>> http://www.ssTk.co.uk
>> ___
>> 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
>



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

Re: [osg-users] Remote execution and OSG

[Simon Hammett]

Don't you have to grant access on your machine to remote connections?
IIRC, try 'xhost +' on your machine before starting the program on the
remote machine.

2009/5/14  :
>
> Yes, I am using Redhat Linux with OSG 2.9.3.
>
> Using "ssh -Y" didn't help...
>
> Also, as I pointed out in my last e-mail, I get this X11 connection refused, 
> however, the application still runs but FULL SCREEN instead of in a window...
>
> Paul P.
>
>
> - Original Message 
> From: "Thrall, Bryan" 
> To: OpenSceneGraph Users 
> Sent: Thursday, May 14, 2009 1:35:45 PM
> Subject: Re: [osg-users] Remote execution and OSG
>
> paul1...@yahoo.com wrote on Thursday, May 14, 2009 12:28 PM:
>
>> I need to be able to run my OSG program remotely (from a different machine
>> that where the display location). I'm using "ssh" to login to the remote
>> location and have my "setenv DISPLAY" set back to my original computer (I've
>> set xhost + on the server machine).
>>
>> When I do this, on SOME OSG examples, I'm getting:
>> Xlib: connection to ":0.0" refused by server
>> Xlib: No protocol specified
>>
>> Error: Unable to open display ":0.0".
>> Error: unable to create graphics window
>>
>> I haven't narrowed down when I get this but it seems that I get it only when
>> I run applications that create their own windows. I do not see this when
>> running osgviewer in full screen mode nor with many of the other OSG
>> examples. However, I do see this problem with osgkeyboardmouse,
>> osgcompositeviewer, osgsidebyside, osgtexture3D, osgslice,  and osgwindows.
>> In these cases, instead of opening up a window as I think these are supposed
>> to do, it runs full screen.
>>
>> Any idea what is going on here?
>
> Not sure what's wrong with your DISPLAY, but 'ssh -Y' will tunnel the X 
> connection through ssh and set up the DISPLAY correctly (usually to something 
> like 'localhost:10.0') without you having to mess with it.
>
> You don't say, but I'm assuming you're running Linux or something like that; 
> OSG compiled for Windows doesn't do X forwarding :)
>
> --
> Bryan Thrall
> FlightSafety International
> bryan.thr...@flightsafety.com
> ___
> 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
>



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

Re: [osg-users] Remote execution and OSG

[Simon Hammett]

No idea, sry.
It's getting on for 15 years since I did any xlib programming.

You could have a poke around in:

src\osgViewer\GraphicsWindowX11.cpp

and work backwards from there.

2009/5/14  :
>
> Already tried "xhost +".. No help..
>
> What is so special about "osgkeyboardmouse, osgcompositeviewer, 
> osgsidebyside, osgtexture3D, osgslice,  and osgwindows" that would cause them 
> not to work but other do?  "osgviewer --window" seems to work fine..  Does 
> this have something to do with the GraphicsContext?
>
> Paul P.
>
>
> - Original Message 
> From: Simon Hammett 
> To: OpenSceneGraph Users 
> Sent: Thursday, May 14, 2009 2:58:09 PM
> Subject: Re: [osg-users] Remote execution and OSG
>
> Don't you have to grant access on your machine to remote connections?
> IIRC, try 'xhost +' on your machine before starting the program on the
> remote machine.
>
> 2009/5/14  :
>>
>> Yes, I am using Redhat Linux with OSG 2.9.3.
>>
>> Using "ssh -Y" didn't help...
>>
>> Also, as I pointed out in my last e-mail, I get this X11 connection refused, 
>> however, the application still runs but FULL SCREEN instead of in a window...
>>
>> Paul P.
>>
>>
>> - Original Message 
>> From: "Thrall, Bryan" 
>> To: OpenSceneGraph Users 
>> Sent: Thursday, May 14, 2009 1:35:45 PM
>> Subject: Re: [osg-users] Remote execution and OSG
>>
>> paul1...@yahoo.com wrote on Thursday, May 14, 2009 12:28 PM:
>>
>>> I need to be able to run my OSG program remotely (from a different machine
>>> that where the display location). I'm using "ssh" to login to the remote
>>> location and have my "setenv DISPLAY" set back to my original computer (I've
>>> set xhost + on the server machine).
>>>
>>> When I do this, on SOME OSG examples, I'm getting:
>>> Xlib: connection to ":0.0" refused by server
>>> Xlib: No protocol specified
>>>
>>> Error: Unable to open display ":0.0".
>>> Error: unable to create graphics window
>>>
>>> I haven't narrowed down when I get this but it seems that I get it only when
>>> I run applications that create their own windows. I do not see this when
>>> running osgviewer in full screen mode nor with many of the other OSG
>>> examples. However, I do see this problem with osgkeyboardmouse,
>>> osgcompositeviewer, osgsidebyside, osgtexture3D, osgslice,  and osgwindows.
>>> In these cases, instead of opening up a window as I think these are supposed
>>> to do, it runs full screen.
>>>
>>> Any idea what is going on here?
>>
>> Not sure what's wrong with your DISPLAY, but 'ssh -Y' will tunnel the X 
>> connection through ssh and set up the DISPLAY correctly (usually to 
>> something like 'localhost:10.0') without you having to mess with it.
>>
>> You don't say, but I'm assuming you're running Linux or something like that; 
>> OSG compiled for Windows doesn't do X forwarding :)
>>
>> --
>> Bryan Thrall
>> FlightSafety International
>> bryan.thr...@flightsafety.com
>> ___
>> 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
>>
>
>
>
> --
> http://www.ssTk.co.uk
> ___
> 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
>



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

Re: [osg-users] What is everyone doing for GUIs?

[Simon Hammett]

If you want a proper cross platform gui with all the bells and whistles,
the three main choices are probably Qt, WxWidgets or Gtk.

Qt is probably the most powerful and fully featured, but you have to
use that dam MOC thing
and the Qt framework.

WxWidgets seems to give quite small programs, but it's not very pretty.

Gtk is quite nice but maybe an arse to install on windozes, there's
dozens of dlls for it.

If you want something rendered by Gl, there's Crazi eddies Gui.
Don't know of anything else that's reasonably complete,
there wasn't many around last time I looked for one, but that
was a year ago or so.

2009/5/16 Mike Hall :
> Hey All,
>
> What are you all doing for GUI development in OSG?
>
> QT, WxWidgets, Roll you own etc?
>
> We are designing a system, and we would like to know what the majority of 
> people out there are using. We would like to have menus, mouse clicks, 
> dialogs, buttons etc.
>
> Thanks,
>
> skibud2
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=12313#12313
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] moving the camera to predefined locations smoothly

[Simon Hammett]

2009/5/19 Ulrich Hertlein :
> Hi Cory,
>
> On 18/5/09 8:43 PM, Cory Riddell wrote:
>>
>> changes. I don't know what the correct parametric equation for moving a
>> camera between two points on the surface of a sphere is. I changed my
>> code to move the camera along a chord from point A to point B and that
>> seems to work just fine.
>>
>> Any idea what the parametric equation for the arc connecting to points
>> on a sphere is?
>
The rotation axis is the cross product of the two vectors from A and B
to the center of the sphere.

You need to take special care when A & B are almost perpendicular though...

In that case you'll just have to chose an up vector and take the cross
product of with A or B and that, because you get a zero vector.

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

Re: [osg-users] Picking and ignoring clipped parts of models?

[Simon Hammett]

2009/5/21 Paul Griffiths :
>
> Paul Martz wrote:
>> The scene graph that you perform the pick on doesn't have to be the same
>> scene graph as the one you display, if that helps.
>
>
> No, my scene is a bit too complicated for that. It's for a new 3D gui system 
> im creating called RedWidget!
>
> I really do need to ignore cliped parts of models/scene.
> Having 2 scenes when theres loads of buttons, tables,windows and scroll 
> panels etc would get a bit too complicated.
> .

Which picker are you using?

If it's the polytop one, don't forget that that picks by using a picking volume
consisting of planes. You could modify the volume it's using or add an
extra plane if need be. Anything on the -ve sides of the pick planes
is not considered; which is pretty much the same as clipping.

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

Re: [osg-users] BoundingSphere and IntersectionTest

[Simon Hammett]

2009/5/21 Matthias Gabriel :
> Hi,
> today i wanted to build my own "LineSegmentIntersector" - well some kind
> of... while doing this, i looked into the sourcecode of the
> LineSegmentIntersector. There I saw, that the tests in
> "LineSegmentIntersector::intersects(..)" refer to start and end point of the
> lsi on the one hand, and to boundsphere.center()/radius() on the other hand.
> But here is my Problem. Start and end- points are in world coordinates,
> while the boundingsphere is in local coordinates...somewhere here in the
> newsgroup a read, that boundingssphere only refers to their children..
>
> I came to this problem, while implementing my own
> Intersect-Bounding-Algorithms, where i get wrong results... Why is the
> original LinesegmentIntersector working or: is it actually working?
>
> At which point am i missunderstanding this?
>
> Thanks für your Help,
> MG

As you traverse the scene graph, you maintain a matrix stack in the same way
that open gl does.
Enter a transform, push your stack, multiply the transform into it.
Leave a transform and pop your stack.

Then when you want to do the intersection, you can either transform the bounding
sphere into world coordinates or transform your pick ray into local coordinates.

It's easier to transform the ray, but then you have to pay for a matrix invert.

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

Re: [osg-users] Compute axis aligned bounding box of a given size

[Simon Hammett]

2009/5/22 Paul Griffiths :
> Hi,
> I wish to compute an axis aligned bounding box of a given size whos position 
> is centered to a node.
>
> This node cound be scaled, translated or rotated. it must be axis aligned.
>
> I need to know this to test if a picked part of a node picked with the mouse 
> is inside the bounds a bounding box surrounding the node, but i need to 
> spesify the size.
>
> ...
>
> Thank you!
>
> Cheers,
> PaulG
>

LineSegmentIntersector::Intersection has a member: matrix
which is the accumulated local to world coordinates matrix.

If you transform the nodes BoundingSphere center by that, you
can then construct an aabb around that at whatever size you want.

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

Re: [osg-users] Compute axis aligned bounding box of a given size

[Simon Hammett]

2009/5/22 Paul Griffiths :
> Im clipping an osg::group with an osg::ClipNode so parts of it is invisible 
> on screen but when i click on the invisible parts the picker is still picking 
> the object . i dont want it like that, i want the invisible parts to be 
> invisible to the mouse as well. so i wish to create an aabb around the parent 
> picked node the same size and position as the clipNode and check if 
> getWorldIntersectPoint is within this aabb.
>
> if there is a way to check if getWorldIntersectPoint is outside a clipnodes 
> assigned bounding box then that would be even better.
>
>
> It's for a scrollpanel for my new 3d gui system.
>

If you have a clip node in world coordinates, you can just test the
world intersect point against that.

for each clip plane in the clip node, call getClipPlane,

this gives you a vec4d which is the plane equation.
calc the distance from the plane and if it's negative it's outside.

distance is pt.x() * pl.x() + pt.y() * pl.y() + pt.z() * pl.z() + pl.w()
where pt is the intersection point
and pl is the vec4 of the plane

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

Re: [osg-users] Compute axis aligned bounding box of a given size

[Simon Hammett]

2009/5/22 Simon Hammett :
> 2009/5/22 Paul Griffiths :
>> Im clipping an osg::group with an osg::ClipNode so parts of it is invisible 
>> on screen but when i click on the invisible parts the picker is still 
>> picking the object . i dont want it like that, i want the invisible parts to 
>> be invisible to the mouse as well. so i wish to create an aabb around the 
>> parent picked node the same size and position as the clipNode and check if 
>> getWorldIntersectPoint is within this aabb.
>>
>> if there is a way to check if getWorldIntersectPoint is outside a clipnodes 
>> assigned bounding box then that would be even better.
>>
>>
>> It's for a scrollpanel for my new 3d gui system.
>>
>
> If you have a clip node in world coordinates, you can just test the
> world intersect point against that.
>
> for each clip plane in the clip node, call getClipPlane,
>
> this gives you a vec4d which is the plane equation.
> calc the distance from the plane and if it's negative it's outside.
>
> distance is pt.x() * pl.x() + pt.y() * pl.y() + pt.z() * pl.z() + pl.w()
> where pt is the intersection point
> and pl is the vec4 of the plane
>
> --
> http://www.ssTk.co.uk
>

It's also worth noting, that the LineSegmentIntersector::Intersection
result has a nodePath member which is the trace from the top of the scene
graph to that node.

This can be used with the functions in osg/Transform to give you various
useful matrices.

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

Re: [osg-users] Compute axis aligned bounding box of a given size

[Simon Hammett]

2009/5/22 Paul Griffiths :
> Ive came up with this but it returns outside true every time regardless:
>
>
> Code:
>
> bool outside = false;
> if (obj->getParentWidget() && 
> obj->getParentWidget()->getUsingClipBoundingBox())
> {
>    osg::ref_ptr clipNode = 
> obj->getParentWidget()->getClipNode();
>    if (clipNode)
>    {
>        for (unsigned int i = 0; i < clipNode->getNumClipPlanes(); i++)
>        {
>           osg::ref_ptr plane = clipNode->getClipPlane(i);
>           osg::Vec4d pl = plane->getClipPlane();
>           osg::Vec3d pt = hitr->getWorldIntersectPoint();
>           if (( pt.x() * pl.x() + pt.y() * pl.y() + pt.z() * pl.z() + pl.w() 
> ) < 0.f)
>           {
>               outside = true;
>               break;
>           }
>       }
>    }
> }
>
>
>
>
> i set the clip node like:
>
> Code:
>
> this->clipBoundingBox.set(pos.x() - this->size.x(),pos.y() - 
> this->size.y(),pos.z() - this->size.z(),pos.x() + this->size.x(), pos.y() + 
> this->size.y(), pos.z() + this->size.z());
> this->clipNode->createClipBox(this->clipBoundingBox);
> this->panel.setStateSet(this->clipNode->getStateSet());

Okies, if memory serves me correctly, the clip planes aren't in world
coordinates,
I think they are in eye coordinates.

So that would be take the local intersection coordinate and transform it using
computeLocalToEye (in osg/Transform) and test that point.

If that doesn't work, you'll need to post another question for how to do that.

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

Re: [osg-users] Compute axis aligned bounding box of a given size

[Simon Hammett]

2009/5/22 Paul Griffiths :
>
> Simon Hammett wrote:
>>
>> Okies, if memory serves me correctly, the clip planes aren't in world
>> coordinates,
>> I think they are in eye coordinates.
>>
>> So that would be take the local intersection coordinate and transform it 
>> using
>> computeLocalToEye (in osg/Transform) and test that point.
>>
>> If that doesn't work, you'll need to post another question for how to do 
>> that.
>
>
> Im a little confused how to do what you have suggested.
> the method is : Matrix computeLocalToEye(const Matrix& modelview, const 
> NodePath& nodePath, bool ignoreCameras = true)

if you have a viewer, the model view matrix is
pViewer->getCamera()->getViewMatrix();

> what do i put for the modelView? is the nodePath from the picker?
> and do i go like pt *= computeLocalToEye(modelview, nodePath) to transform 
> the point?

I think so. Try that.
If it doesn't work I'm out of ideas, but I'll have a play when I get
home tonight.

> And thanks for all your help :)))
>
No worries.
You've got me interested in this, I'm probably going to need something
similar for the stuff I'm doing at some point.

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

Re: [osg-users] Compute axis aligned bounding box of a given size

[Simon Hammett]

2009/5/22 Simon Hammett :
> 2009/5/22 Paul Griffiths :
>>
>> Simon Hammett wrote:
>>>
>>> Okies, if memory serves me correctly, the clip planes aren't in world
>>> coordinates,
>>> I think they are in eye coordinates.

Right I've had time to play with ClipNode, and what I said above is rubbish.

You just need the matrix which transforms from the parent to the
intersection node.

Given you are writing a tool kit, I suspect you can quickly and easily work out
that transform from your objects.

If not you to just need to find the parent node in the 'nodePath'
member of the intersection result and then run through to the end of
the nodePath
accumulating any matrices you find.

Then invert that matrix and multiply the intersection point with it
and test it to inside
or outside your clip node as appropriate.

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

Re: [osg-users] Compute axis aligned bounding box of a given size

[Simon Hammett]

> Which way would be better, what i have now or what you just suggested?

My rule of thumb is; unless you have a compelling reason (ie efficiency),
you should always prefer your own solutions.

That way if you have to bug fix it or improve
it in 1,2,3 years time you might remember what you did.

> Thank you Simon, your suggestions helped me loads!

You're welcome, glad I helped rather than hindered! :)

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

Re: [osg-users] Single-sided ClipPlane?

[Simon Hammett]

2009/5/23 Paul Griffiths :
> My second idea of how to create my effect has a flaw, if the rear contents of 
> 2 scrollpanels overlap then ill get the contents of the scrollpanels inside 
> each other.
>
> If anyone knows how to create single-sided clipPlanes which only clip when 
> viewed from one side and when viewed from the other side do not clip then do 
> post, its what I need.
>

Lol, I knew you where going to wind up asking this question.

The idea solution is portal rendering.
No mucking about with stencil buffers or render to texture.

However I don't think osg supports portal rendering,
and modifying the render stage to support it isn't
exactly trivial.

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

Re: [osg-users] Single-sided ClipPlane?

[Simon Hammett]

2009/5/23 Paul Griffiths :
> Enabling/disabling clipPlanes won't do the job, your looking at the side and 
> into the scroll window at the same time.
>
> >From what i can work out, clipPlanes slice all the way along the model and 
> >remove the outer half, so any clipping applied is going to effect what I see 
> >at the front of the scroll window too.
>
> Or am I missing something?
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=12839#12839

Is this what you are after?

http://www.sstk.co.uk/portalRendering/portal.php

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

Re: [osg-users] Single-sided ClipPlane?

[Simon Hammett]

2009/5/24 Paul Martz :
>> http://www.sstk.co.uk/portalRendering/portal.php
>
> Unless I'm missing something, couldn't you do this in OSG using an Occluder
> (for host-side culling) and the stencil buffer (to control screen
> rendering)?
>
You don't even need that.

Just set up the clip planes properly.

Translate the cameras position into the portals coordinate frame,
then use each edge of the portal and the camera position to construct
a clip plane.

This should be easy to do in osg.

Just need to know where to put the callback.

Course it will all go pear shaped if the stuff though the portal uses
clip planes,
unless your h/w supports lots of them.

But I suspect that might happen even with using the stencil buffer.

I think you need to get clever to support multi level portals. ie ones where
you can see a portal through a portal.

IIRC most games with portal rendering don't support multiple levels.

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

Re: [osg-users] Single-sided ClipPlane?

[Simon Hammett]

2009/5/24 Paul Griffiths :
> Just to let people know, portals is not quite what im looking for, its more 
> of an extended type portal, i believe a portal is a plane with a texture of a 
> scene applied to give to look of a scene within a scene, im looking for 
> scenes within scenes but with models coming out from the portal front too.
>
portals don't use textures. it's just clip planes, though
you will need to clear the depth buffer within the portal.

if you want the model sticking out the front you'll have to
have another instance of it, with the in portal side clipped off.

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

Re: [osg-users] Consistent lighting across different cameras

[Simon Hammett]

Just a quick guess, but are you putting rotation into your left &
right projection matrices?
If so that's what's mucking up your lighting:

http://sjbaker.org/steve/omniv/projection_abuse.html

2009/7/6 Julian Looser :
> Hi,
>
> I am using OSG in a multi-wall stereo rendering environment. We have three
> walls, and we render both a left and right eye view for each wall. To do
> this, in my application I create six osg::Cameras and update their
> projection and view matrices each frame based on head-tracking. I add the
> same subgraph under each camera, and I get a seamless 3D scene across the
> three walls. So far so good.
>
> My problem is with lighting. Although the 3D geometry is rendered in the
> right place, it isn't lit correctly. For example, sometimes the left view
> might be much brighter than the center view, which in turn is brighter than
> the right view. This has me confused because all six cameras are rendering
> the exact same scene, and the light is part of the scene (rather than a
> head-light of the viewer for example).
>
> My scene graph is set up basically like this (just showing three rather than
> six cameras). The cameras all share the same child subgraph, and just render
> to viewports next to each other across a window.
>
> root
> -- camera (mv & proj for left wall)
>  --- model
>  --- lightsource
> -- camera (mv & proj for center wall)
>  --- model
>  --- lightsource
> -- camera (mv & proj for right wall)
>  --- model
>  --- lightsource
>
> I've attached a picture of the effect I'm getting. What I expected would be
> that the object (just a long red box) would be smoothly lit along its
> length. However, when it spans across my three views, you can see it's
> darker or lighter in each view, suggesting that the lightsource isn't in the
> same place within each rendering.
>
> Am I putting my lightsource in the wrong place in the scene graph? I thought
> it should be a sibling to what you want lit? Even though the projection and
> view matrices are different for each camera, the lighting should be
> consistent, right?
>
> I'm using a composite viewer, and each view I create I've set the lighting
> mode to NO_LIGHT, so I don't think it's a default light causing any trouble.
> The only light should be the one in my scene.
>
> If you have any ideas why this is happening I would really appreciate
> hearing them! :-)
> Thanks,
> Julian.
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>



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

Re: [osg-users] readNodeFile model not visible through a semi-transparent box

[Simon Hammett]

Depth sorting for transparency happens at a course level in osg.
I think it uses the center of the bounding box of the geometry object.

For your specific example you'll need to place the 6 cube faces into
separate geometries to get
the result you expect.

If you want to make a complex model transparent have a look at the
depth peeling example.

2009/7/11 Gotthard, Petr :
> Hello,
>
>
>
> I have troubles visualizing a 3D model (e.g. an aircraft) loaded using the
> readNodeFile() function when this model is inside a semi-transparent box.
>
>
>
> I create the semi-transparent box, set alpha value and enable blending by
>
> state-->setMode(GL_BLEND, osg::StateAttribute::ON);
>
> state-->setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
>
>
>
> When I load some model using readNodeFile and put it into the box, some
> parts of the model disappear (get culled) when seen from outside the box,
> while other don’t. For example, aircraft body disappear so that pilot seats
> that were inside the aircraft are visible.
>
> If I move camera inside the box, I see the whole model inside the box is
> visualized correctly.
>
>
>
>
>
> Do you have any idea what should I do to have the model-in-a-box displayed
> correctly?
>
>
>
> I guess I should probably call some setMode or setRenderingHint function
> also for the model. Do I have to walk through all nodes in the subgraph
> loaded by readNodeFile, or is there a function that should be called on the
> subgraph root only?
>
>
>
> Best Regards,
>
> Petr
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>



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

Re: [osg-users] Help with CompositeViewer

[Simon Hammett]

You've forgotten to setup the viewport I think:

view->getCamera()->setViewport(new osg::Viewport(0,0, traits->width/2,
traits->height/2));

2009/7/24 Vic Ace :
> And setting the clearcolor for the camera did not give the same effect. still 
> just black. hmm.
> view->getCamera()->setClearColor(osg::Vec4f(0.2f, 0.2f, 0.6f, 1.0f));
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=15407#15407
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>

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

Re: [osg-users] Help with CompositeViewer

[Simon Hammett]

That's how it should look.

You've set the viewport up to take a quarter  of the screen and you
don't have a camera manipulator,
so your camera will be in the default location, which usually means
you aren't looking at anything.

Remove the /2 in the viewport setup or add some more view ports to
fill the rest of the window.

To look at some thing you either need a camera manipulator:

pView->setCameraManipulator(new osgGA::TrackballManipulator);

or you need to write your own code to orientation the camera's viewMatrix.

2009/7/24 Vic Ace :
> Ok, now the code looks like this and I have attached a pic of how this 
> renders. A bit odd.
>
>
> Code:
> osg::ref_ptr viewer = new 
> osgViewer::CompositeViewer;
>
> osg::ref_ptr traits = new 
> osg::GraphicsContext::Traits;
> traits->x = 100;
> traits->y = 100;
> traits->width = 800;
> traits->height = 600;
> traits->depth = 16;
> traits->windowDecoration = true;
> traits->supportsResize = false;
> traits->windowName = "TEST";
> traits->doubleBuffer = true;
>
> osg::ref_ptr graphicscontext = 
> osg::GraphicsContext::createGraphicsContext(traits);
>
> osg::ref_ptr root = new osg::Group;
> osg::ref_ptr geode = new osg::Geode;
> osg::ref_ptr capsule = new osg::Capsule(osg::Vec3(), 1, 2);
> osg::ref_ptr drawable = new osg::ShapeDrawable(capsule);
> geode->addDrawable(drawable);
> root->addChild(geode);
>
> osg::ref_ptr view = new osgViewer::View;
> viewer->addView(view);
> view->setSceneData(root);
> view->getCamera()->setGraphicsContext(graphicscontext);
> view->getCamera()->setClearColor(osg::Vec4f(0.2f, 0.2f, 0.6f, 1.0f));
> view->getCamera()->setViewport(new osg::Viewport(0 , 0, traits->width / 2, 
> traits->height / 2));
>
>
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=15412#15412
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>



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

Re: [osg-users] [build] Building a Simple Viewer

[Simon Hammett]

Set you include directories list to:

C:\Praktikum\OpenSceneGraph\OSG\include\
C:\Praktikum\OpenSceneGraph\OSG\build\include\

Then it should work. You're going too far down in the directory hierarchy.

2009/8/3 David Goering :
> Okay here is something interesting:
>
> I deleted all of my includes to start linking to the includes from scratch 
> and just  continue until he finds all the files (that was my hope  |-) )
> anyway, I added in:
> "C:\Praktikum\OpenSceneGraph\OSG\build\include\OpenThreads"
> because he said he couldn't find "Config".
> Once I did that he said he couldn't find "osgViewer/Viewer"
> so I added in: "C:\Praktikum\OpenSceneGraph\OSG\include\osgViewer\" and 
> changed the include I had at the top to
> "#include "Viewer"
> #include "ViewerEventHandlers" "
> so that he can find those (since I couldnt find osgViewer/Viewer in the build 
> directory).
> But now I am stuck trying to include osg/ArgumentParser, because I have to 
> look for that in "...\OSG\include" and if I add that to the include Path he 
> looks  there for OpenThreads but can't find the Config... so I am back at the 
> beginning  :'
> Am I doing something wrong, or any ideas what I could do differently  :?
> Thanks,
> David

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

Re: [osg-users] OSG and shaders

[Simon Hammett]

http://www.typhoonlabs.com/

Download chapters 1 through 5 and ShaderDesigner.

Very very handy.

There's also the orange book: (though I've not read it myself)

http://www.amazon.com/OpenGL-Shading-Language-Randi-Rost/dp/0321637631

2009/8/3 Hadrien Thomas :
> Hi!
>
> I just registered to this forum. I hope I am not a kind of intruder or 
> something.
>
> I am starting right now a 6 month internship.
> I have to build a library of effects with GLSL and OSG.
>
> The problem is that I'm not used to OSG (but I had some courses for 
> OpenInventor which has the same system of graphs) at all and worst: I've 
> never used shaders before.
>
> What do you recommand me to do?
>
> I don't understand any results of my searchs on openscenegraph.org about 
> shaders. The search engine may have some issues, or I don't know how it works.
>
> Perhaps can you enlight me on some tutorials about how to use shaders from A 
> to Z (just simple, I'm not begging for a complex thing but just how it 
> works!) or where I can find any documentation.
>
> Thank you very much for your help.
>
> Hadrien.
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=15717#15717
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] Transparent Background

[Simon Hammett]

You should be able to render to a transparent screen, just set the
clear colour alpha to 0.

I don't think compositing with the desktop is directly supported by osg though.
You'll need to platform specific magic for that.

2009/8/3 Martin Großer :
> Hello,
>
> short question. Is it possible to make a transparent background. That means
> I would like see only my 3D objekt on my desktop.
>
> Cheers,
>
> Martin
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] [build] LNK2019: declspec(dllimport)

[Simon Hammett]

I'm guessing 'Nicht aufgelöstes externes' means symbol not found.

You need to make sure your exe and the dlls are all using the same
Runtime Library option.

Do project properties -> C/C++ -> Code Generation
and check the 'Runtime Library' line.

That has to be the same for everything and should generally be:
 'Multi-threaded Debug DLL' for debug builds
 'Multi-threaded DLL' for release.

2009/8/3 David Goering :
> Hey, its me... again... |-)
> I got the OpenSceneGraph Viewer Window working, now I added OsgArt libraries 
> to the linker, in order to use the funcionality of OSGART, now I always get 
> the following error:
>
>
> Code:
> OsgArtTest error LNK2019: Nicht aufgelöstes externes Symbol 
> '"__declspec(dllimport) public: class std::basic_ostream std::char_traits > & __thiscall std::basic_ostream std::char_traits >::flush(void)" 
> (__imp_?fl...@?$basic_ostream@du?$char_tra...@d@std@@@std@@qaeaa...@xz)', 
> verwiesen in Funktion '"class std::basic_ostream std::char_traits > & __cdecl std::endl(class 
> std::basic_ostream > &)" 
> (?e...@std@@yaaav?$basic_ostr...@du?$char_traits@d...@std@@@1...@aav21@@Z)'
>
>
>
>
> A friend of mine said he thought it had something to do with libs and dlls 
> not playing well together or something like that.
> But I just can't figure out what the problem is exactly. I tried google and I 
> find a lot of people with this problem, but couldnt find a real solution that 
> would apply for me.
> Anyone here run across this error and know a solution ? [Question]
> Cheers,
> David
>

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

Re: [osg-users] OSG and shaders

[Simon Hammett]

>
> Ps: I just noticed that i dont know what are: drawWidth and drawColor. But if 
> it's not the main problem, can you tell me?
>

You're missing a vertex shader. Your program isn't linking.

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

Re: [osg-users] Infinite Grid in OSG

[Simon Hammett]

The clipping you are seeing is probably due to osg's computation of
the near and far clipping planes.
You'll need to implement computeBound so osg knows about your object.
Have a look in ShapeDrawable.cpp

2009/8/10 Andrew Thompson :
> Hi Chris,
>
> Thanks for the heads up, I was digging around and found the 
> drawImplementation method in Drawable myself so decided to give it a go. 
> However I've had less than spectacular results!
>
> My first test was to take the code from ShapeDrawable that draws a box. Here 
> it is for completeness sake
>
>
> Code:
>
>
> void drawImplementation(osg::RenderInfo & renderInfo) const
> {
>   // evaluate hints
>   bool createBody = true;
>   bool createTop = true;
>   bool createBottom = true;
>
>   float dx = 3;
>   float dy = 3;
>   float dz = 3;
>
>   glColor3ub(60,60,60);
>   glPushMatrix();
>
>   glTranslatef(10,10,10);
>
>   glBegin(GL_QUADS);
>
>   if (createBody) {
>      // -ve y plane
>      glNormal3f(0.0f,-1.0f,0.0f);
>
>      glTexCoord2f(0.0f,1.0f);
>      glVertex3f(-dx,-dy,dz);
>
>      glTexCoord2f(0.0f,0.0f);
>      glVertex3f(-dx,-dy,-dz);
>
>      glTexCoord2f(1.0f,0.0f);
>      glVertex3f(dx,-dy,-dz);
>
>      glTexCoord2f(1.0f,1.0f);
>      glVertex3f(dx,-dy,dz);
>
>      // +ve y plane
>      glNormal3f(0.0f,1.0f,0.0f);
>
>      glTexCoord2f(0.0f,1.0f);
>      glVertex3f(dx,dy,dz);
>
>      glTexCoord2f(0.0f,0.0f);
>      glVertex3f(dx,dy,-dz);
>
>      glTexCoord2f(1.0f,0.0f);
>      glVertex3f(-dx,dy,-dz);
>
>      glTexCoord2f(1.0f,1.0f);
>      glVertex3f(-dx,dy,dz);
>
>      // +ve x plane
>      glNormal3f(1.0f,0.0f,0.0f);
>
>      glTexCoord2f(0.0f,1.0f);
>      glVertex3f(dx,-dy,dz);
>
>      glTexCoord2f(0.0f,0.0f);
>      glVertex3f(dx,-dy,-dz);
>
>      glTexCoord2f(1.0f,0.0f);
>      glVertex3f(dx,dy,-dz);
>
>      glTexCoord2f(1.0f,1.0f);
>      glVertex3f(dx,dy,dz);
>
>      // -ve x plane
>      glNormal3f(-1.0f,0.0f,0.0f);
>
>      glTexCoord2f(0.0f,1.0f);
>      glVertex3f(-dx,dy,dz);
>
>      glTexCoord2f(0.0f,0.0f);
>      glVertex3f(-dx,dy,-dz);
>
>      glTexCoord2f(1.0f,0.0f);
>      glVertex3f(-dx,-dy,-dz);
>
>      glTexCoord2f(1.0f,1.0f);
>      glVertex3f(-dx,-dy,dz);
>   }
>
>   if (createTop) {
>      // +ve z plane
>      glNormal3f(0.0f,0.0f,1.0f);
>
>      glTexCoord2f(0.0f,1.0f);
>      glVertex3f(-dx,dy,dz);
>
>      glTexCoord2f(0.0f,0.0f);
>      glVertex3f(-dx,-dy,dz);
>
>      glTexCoord2f(1.0f,0.0f);
>      glVertex3f(dx,-dy,dz);
>
>      glTexCoord2f(1.0f,1.0f);
>      glVertex3f(dx,dy,dz);
>   }
>
>   if (createBottom) {
>      // -ve z plane
>      glNormal3f(0.0f,0.0f,-1.0f);
>
>      glTexCoord2f(0.0f,1.0f);
>      glVertex3f(dx,dy,-dz);
>
>      glTexCoord2f(0.0f,0.0f);
>      glVertex3f(dx,-dy,-dz);
>
>      glTexCoord2f(1.0f,0.0f);
>      glVertex3f(-dx,-dy,-dz);
>
>      glTexCoord2f(1.0f,1.0f);
>      glVertex3f(-dx,dy,-dz);
>   }
>
>   glEnd();
>   glPopMatrix();
> }
>
>
>
>
>
> This results in a gray box drawn at the location 10,10,10 of size 3,3,3.
>
> [Image: http://i137.photobucket.com/albums/q217/andyb1979/drawImpBefore.png ]
>
> However, if I add other objects to my scene, then the box renders incorrectly.
>
> [Image: http://i137.photobucket.com/albums/q217/andyb1979/drawImpAfter.png ]
>
> At this point the subgraph looks like this, the additional objects from the 
> position attitude transforms (labelled PAT) onwards are added when the cones 
> are in the scene.
>
> [Image: http://i137.photobucket.com/albums/q217/andyb1979/Subgraph.png ]
>
> Another example, what I actually want to do is draw a subdividing grid that 
> extends to the horizon. The code for this (at present) is included below
>
>
> Code:
>
> void drawImplementation(osg::RenderInfo & renderInfo) const
> {
>   currentState->applyMode(GL_LIGHTING, false);
>   glColor3ub(60,60,60);
>
>   //render floor grid
>   glLineWidth(1.0f);
>   glBegin(GL_LINES);
>
>   // Compute the Z location of the grid
>   int zg = (int)0;
>   int ystep = 100;
>   int xstep = 100;
>
>   // Compute the Y-Step depending on the current zoom factor
>   if(m_zoom < 1.5)
>      ystep = xstep = 10;
>   if(m_zoom < 0.8)
>      ystep = xstep = 5;
>   if(m_zoom < 0.4)
>      ystep = xstep = 2;
>   if(m_zoom < 0.2)
>      ystep = xstep = 1;
>
>   // Compute the min/max X and Y values for each line
>   float miny = (m_posY-(m_vHeight/2*m_zoom));
>   float maxy = (m_posY+(m_vHeight/2*m_zoom));
>   float minx = (m_posX-(m_vWidth/2*m_zoom));
>   float maxx = (m_posX+(m_vWidth/2*m_zoom));
>
>   // Draw lines in the Y direction
>   for(int yg = (int)(miny - ((int)miny%ystep)); yg <= (int)(maxy - 
> ((int)maxy%ystep)); yg+=ystep){
>      glColor3ub(60,60,60);
>      if(yg%10 == 0){
>         glEnd();
>         glColor3ub(100,100,100);
>         glLineWidth(2.0f);
>         glBegin(GL_LINES);
>      }
>      if(yg%100 == 0)
>         glColor3ub(180,180,180);
>      glVertex3f(minx, (GLfloat)yg, (GLfloat)zg);
>      glVertex3f(maxx, (GLfloat)yg, (GLfloat)zg);
>      if(yg%10 =

Re: [osg-users] about the bounding sphere of a geode computed by OSG

[Simon Hammett]

Calculating the perfect bounding sphere is an expensive operation.
You need to calc the convex hull which is O(n log n).
osg uses a fast approximation which is generally good enough.

2009/8/11 Gianluca Natale :
> Hi All,
> I’m having problem computing the global bounding sphere of my model.
> I debugged OSG (2.8.0) and discovered that the bounding sphere of a geode
> (BoundingSphere Geode::computeBound()) is
> computed as the bounding sphere of the bounding box that includes all its
> drawables !?!
>
>
>
> Why that?
>
> Shouldn’t it be the global bounding sphere of the drawables, merging the
> single bounding spheres
> of all the drawables?
>
>
>
> So, a drawable that represents a sphere should have as bounding sphere
> itself,
> but this is not true with the computation OSG performs. It is larger than
> strictly required.
>
>
>
> Thanks,
> Gianluca Natale
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>



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

[osg-users] Material editor/designer?

[Simon Hammett]

Anybody know of a osg compatible material editor/designer?
Repeating the edit/compile/link/curse cycle is starting to get a little tedious.

I'm sure I saw a post about one not so long ago, but I'm damned if I
can find it now.

tia.

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

Re: [osg-users] viewer.frame() rendering not complete

[Simon Hammett]

Try glFinish after frame()

2009/8/11 Rabbi Robinson :
> Hi,
>
> I save it in a file. The problem is with frame(). If I call viewer.run() and 
> hit Esc to quit the viewer the image is complete.
>
> Thank you!
>
> Cheers,
> Rabbi
>

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

Re: [osg-users] Viewer creation and frame() from different threads

[Simon Hammett]

>>>
>>> is it OK to create a viewer in e.g. the main thread and then call frame()
>>> from a different thread? We're getting erratic results on Linux vs
>>> Windows
>>> vs Mac. So I just want to know if this use case is "legal".
>>
>> I've done this under Linux - the osgqtbrowser example in svn/trunk has
>> the option of creating a background thread form running the frame loop
>> while qt takes control over the main thread.  I haven't tested this
>> under Windows or OSX though.  OSX I wouldn't be surprised at problems
>> as it has a really stupid limitation of only getting window events
>> from the main thread - you simply can't poll for events in any other
>> thread.  I don't know what the status is under Windows though.  X11
>> copes just fine with getting events from any thread in your app -
>> sometimes the oldest tech still totally outstrips the new...
>
> this confirms my findings. Our app runs fine on Linux, on Mac we have to do
> something in the main thread to make sure the view updates, on Windows we
> are not sure if it is working or not. I will try osgqtbrowser on Windows and
> see what happens.
>
> Anyone else have reports on osgqtbrowser on Windows?
>
> thanks
> jp
>
Windozes is same as Mac, only the owner thread can retrieve events for windows.
-- 
http://www.ssTk.co.uk
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Viewer creation and frame() from different threads

[Simon Hammett]

2009/10/20 J.P. Delport :
> Hi Simon,
>
> Simon Hammett wrote:
>>>
>>> I will try osgqtbrowser on Windows and
>>> see what happens.
>>>
>>> Anyone else have reports on osgqtbrowser on Windows?
>>>
>>> thanks
>>> jp
>>>
>> Windozes is same as Mac, only the owner thread can retrieve events for
>> windows.
>
> can you expand on what you mean by "owner". If a thread other than main
> creates the viewer and that same thread calls frame(), will that work on
> Windows?
>
> jp

Sort of.

When a thread first creates a window, windows also creates the message
queue for the thread.
Windows messages are per thread, so only the thread which owns the
window will see the
messages for the window in it's event loop, so you can't have another
thread process mouse events, etc.

The pure gl stuff does work though, so you can draw from another thread.

With windows you should really make sure only one thread actually
creates windows as if you
have multiple windows in different threads the only safe
synchronisation primitive is MsgWaitForMultipleObjects which is a huge
pain in the butt.

I've had a go at doing a properly separately threaded viewer window
before and even being extra careful I couldn't stop it dead locking.

>
> --
> This message is subject to the CSIR's copyright terms and conditions, e-mail
> legal notice, and implemented Open Document Format (ODF) standard. The full
> disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
>
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.  MailScanner thanks Transtec
> Computers for their support.
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] Epic releases free version of Unreal Editor

[Simon Hammett]

Yeah I spent quite a bit of time playing with the UT editor way back
with the release before UT 2K3
It was crap then and I doubt it's got any better. The last UT sucked
nads. And actually so did the one
before that.

It was pretty much on a par with Valve's 'Hammer Editor' which is also
a massive ball suck,
but hey at least Valve are a success so you might be able to find some
talented level designers
who know how to use it.

And AFAIK they both share roots with the early ID toolset from Doom/Quake days.
At least ID had the excuse of being Pioneers.

Call me cynical but I don't see this as any more than a last gasp of
an irrelevant game dev. studio.

I'm still waiting for DN'em Forever ;)

2009/11/6 Jean-Sébastien Guay :
> Hi all,
>
> I expect most of you have already seen this:
>
> http://www.develop-online.net/news/33198/Epic-releases-free-version-of-Unreal-Engine
>
> I'm mostly interested in this for the toolset, which is apparently very
> robust. If the file formats are reasonably open and we can make plugins to
> read the data that comes out, it may be an excellent way to create very good
> assets for OSG-based projects.
>
> Consider the following scenario: someone has been doing game assets for a
> while now and feels very comfortable in that kind of pipeline. Now, they
> want to start having a family, or maybe just have a more stable work
> schedule without all the crunch times that game development companies still
> impose. Well, companies making simulators, serious games, or other 3D
> products might be able to hire these people more easily if they can adopt
> toolsets that those people are familiar with.
>
> I think that kind of scenario will become more common as the huge teams of
> game artists start aging, which is already starting and will only increase
> in the next few years. Kind of analogous to the general population with all
> the baby-boomers these days.
>
> And on a completely selfish note, I know our own content creation pipeline
> could use some help... Especially once we start integrating more effects,
> it's going to get hairy. So I'll be checking this out for sure to see if it
> can help.
>
> J-S
> --
> __
> Jean-Sebastien Guay    jean-sebastien.g...@cm-labs.com
>                               http://www.cm-labs.com/
>                        http://whitestar02.webhop.org/
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] Epic releases free version of Unreal Editor

[Simon Hammett]

2009/11/7 Jan Ciger :
> Simon Hammett  wrote:
>> I've gotten good results with exporting blender -> .lwo as long as you
>> split your model meshes up the right way, so you can run the smoothing
>>  visitor on it.
>
> Why? There is osg exporter too. Works fine:
> http://projects.blender.org/projects/osgexport/

Well .lwo was the first format I found that worked and it's binary so
the models load quickly.
The apps I work on, load lots of stuff outta dbs, run third party dlls
& black boxes etc
on start up, so they are already irritatingly slow to start up.

There's also the problem with setting up new machines to run a project;
It takes ages to join the code co-op projects, install boost & other libraries,
black boxes, etc, etc. Adding another step of installing blender and
then getting
the export script as well just makes things take longer.

>> It would be nice if osg could load directly out of .blend files, but the
>>  code in blender that deals with the file format is huge.
>>
>> Maybe somebody who is particularly bored could have a go at
>> refactoring the .blend
>> code into a separate library.
>
> Again, this exists already, even though you probably do not want to do it. The
> .blend files are more containers of a lot of different things than a 
> scenegraph-
> like structure and the mapping will be tricky. The library is called
> "readblend" and comes with the Bullet physics engine.

Nice, thanks for the info, I'll look in to that.

I'd prefer to load models directly out of the .blend file,
it would save mucking about with exporting.

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

Re: [osg-users] Epic releases free version of Unreal Editor

[Simon Hammett]

2009/11/7 Jan Ciger :
> Simon Hammett  wrote:
>>
>> Well .lwo was the first format I found that worked and it's binary so
>> the models load quickly.
>> The apps I work on, load lots of stuff outta dbs, run third party dlls
>> & black boxes etc
>> on start up, so they are already irritatingly slow to start up.
>
> Well, you export to .osg and then you can always convert to binary .ive once
> you are happy with the model.

which is yet another step in the process.
that's making things more complicated, not less.
and .lwo works rather nicely so why change?

>> There's also the problem with setting up new machines to run a project;
>> It takes ages to join the code co-op projects, install boost & other
>>  libraries, black boxes, etc, etc. Adding another step of installing
>>  blender and then getting
>> the export script as well just makes things take longer.
>
> Hmm, how is that different from going the .lwo route? You need Blender
> installed and export to .lwo as well, no?

yes, but you don't have to hunt up the osg exporter script and install that.
again, it's adding yet another step the process.

>
>> Nice, thanks for the info, I'll look in to that.
>>
>> I'd prefer to load models directly out of the .blend file,
>> it would save mucking about with exporting.

> You can actually automate the export - e.g. the Soya3D engine does it in that
> way that whenever the user requests a .blend  file to be loaded, it spawns
> Blender in the background calling it with a command line argument to load the
> model and call the export script. The result is then cached and the model is
> re-exported only when the .blend file is newer than the cached data. The user
> never has to tinker with the exporter, they just notice Blender starting once
> when the model is exported for the first time.
>
> Jan

Well I could do that on my development machine, but I'm not going to
take that route
for client machines.

Sometimes our apps are rolled out to many hundreds of machines;
am I supposed to ask them to install blender, install the export
script, then install our app
x 700 times? That's just not going to fly.

Exporting to .lwo is easy and if that readblend library you mentioned
is a viable route then
I can simplify things by removing another job that I have to do.

btw, do you have any xp with that library?
I'd much appreciate any thing extra you can tell me about it.

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

Re: [osg-users] Epic releases free version of Unreal Editor

[Simon Hammett]

2009/11/7 Jan Ciger :
> Simon Hammett  wrote:
>> which is yet another step in the process.
>> that's making things more complicated, not less.
>> and .lwo works rather nicely so why change?
>
> Because .osg can capture also things that are native to the scenegraph that
> you cannot capture in .lwo (e.g. shaders). Moreover, the compiled .ive is
> optimized by the OSG optimizer, saving even more loading time.

And if I needed shaders or animation I'd be using the osg export script.
Like I said, .lwo does it for me, so why add an extra step?

>> Sometimes our apps are rolled out to many hundreds of machines;
>> am I supposed to ask them to install blender, install the export
>> script, then install our app
>> x 700 times? That's just not going to fly.
>
> Then you are doing it wrong, in my opinion. If you are provisioning 700
> machines, you should have a premade system image with all this preconfigured 
> or
> an installer that will install all the tools the user needs in one go (Blender
> and the scripts are freely redistributable). Then having an extra exporter or
> whatever doesn't matter.
>
> Are you really saying that you are installing (or have the users install) 700
> machines manually?? I do not know your exact situation, but this sounds rather
> crazy to me.

I completely agree, it is crazy.

But we sell s/w to small/medium sized manufacturing companies and that's
the way most of them do this stuff.

We try and persuade them otherwise, but it's very rare for anybody to
ever listen. And even then, our s/w isn't just used directly by the
clients, it's
distributed to their many sales reps who are independent companies of
only 1 or 2 people.

Most the of the sales reps are people who have trouble walking and talking
at the same time, so the install process has to be as simple as possible.

In the manufacturing world most companies have very small profit margins
and are therefore very reluctant to spent money and are very conservative
and as a suppler to those companies, our profits are minimal as well
unfortunately.

My development machine is over 4 years old and my monitor is over 10 years old.
But I get to do quite a bit of graphics work, so that makes up for the
other irritations.

> Anyhow, I am not going to tell you how to do your job - if it works for you,
> by all means stay with it.

I wish we wouldn't...

>> btw, do you have any xp with that library?
>> I'd much appreciate any thing extra you can tell me about it.
>
> No, I didn't try it, I just saw it in Bullet when I have played with it.
>
Ah, ty.

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

Re: [osg-users] Computing Normals for Drawables

[Simon Hammett]

2009/11/9 Andrew Burnett-Thompson :
> Hi guys,
>
> Interesting conversation on solving this problem. I'm working with James on
> this and he's away this week, so I thought I'd reply to keep the
> conversation going, and also to thank you for your input.
>
> Just to throw another requirement into the mix, I don't think we can use
> vertex shaders, as we cannot guarantee what hardware the software will be
> run on. Basically integrated graphics is the lowest possible hardware, so
> what's that, DirectX 8? 9? Vertex shaders run on DX8 but you won't get many
> instructions.
>
> Can this not be done on the CPU side only? Interestingly we did float the
> idea of computing a shared normal array (a sphere coated with normals) for
> all objects in the scene, then provide indices between Geometry vertices and
> the shared normal array, however we really didn't know if this was possible
> in OSG, or if it would work.
>
> A quick look at osg::Geometry source code there is a function
> setNormalIndices, so perhaps if we were to create a NodeVisitor that did the
> following this could work?
>
> 1. On creation of the nodeVisitor, create an osg::Vec3Array for shared
> normals. Populate with normals in all directions.
> 2. As the NodeVisitor walks the tree, for each Geometry object use the code
> from SmoothingVisitor to calculate what the normal should be
> 3. Rather than store that normal in an array and pass to the Geometry,
> instead find the closest normal to it in the shared normal array,
> 4. Store the index to the shared normal, and finally set the indices on the
> Geometry using setNormalIndices
>
> This would be done once on load or creation of an object. It wouldn't matter
> to take the performance hit once per load, nor would it matter if this
> slowed down rendering. We already employ aggressive use of culling to
> achieve decent rendering framerate when the object count is high. The hard
> limit is memory.
>
> Thanks a lot for your input,

The only way to do it with the fixed pipeline I can think of, is basically
just sort all your geometry into group's by the approximate normal, then
you don't have to store the normal index at all so you'd save more memory.

Doing it that way you're using BIND_OVERALL and vertex buffers so
you're still using
osgs fast path. Makes updating geometry a pain, but that doesn't sound like a
problem from your description.

Also with grouping the geometry this way you aren't restricted to a
using a power of
two number of normals, you can just try different numbers of normals
till you get
reasonable looking results.

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

Re: [osg-users] Matrix xform will scale but not translate

[Simon Hammett]

2009/11/15 Darick Barnes 

> Hi,
>
> For some reason I cannot translate my hexagon geode made up of a
> primitiveset of LINE_STRIP
> The scaling works but translation does not.  I am modifying
> AdapterWidget.cpp --MDI  section of the code so that I can use QT4.  It is
> from the osgviewerQt example.  I have tried code in Tut07 and other examples
> but they do not work in this section of
>


It's working fine. By default the camera will centre itself on your scene,
so you can't see the translation.
Add another copy of the model and change the relative positions so you can
see something happening.

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

Re: [osg-users] picture in picture...

[Simon Hammett]

Views get rendered in order added. (at least in single threaded mode)

Just add your 'in picture' viewport last, where you want it.
You will need to turn off clearing of the colour buffer if you want to see
your main scene through the picture .

And maybe call setAllowEventFocus(false); on the views camera to prevent it
nicking
mouse & keyboard events.

2009/11/24 Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC <
shayne.tuel...@hill.af.mil>

>  All,
>
>
>
> This is probably a silly question but what’s the best way to do a “picture
> in picture” using CompositeViewer?
>
>
>
> Right now I have multiple views added to my viewer and I want to have
> control as to which one gets rendered on top of the others in the main
> viewer window…
>
>
>
> Thanx,
>
> -Shayne
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


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

Re: [osg-users] normal vectors aren't causing culling

[Simon Hammett]

2009/11/26 Jim Brooks 

> This is very basic
>
> This test-code snippet is supposed to create a simple square with a
> normal vector (or vectors).
> After rotating it around with the trackball manipulator, the square is
> never culled.
> Same behavior on OSG 2.6 and 2.8.
>

Culling is not enabled by default, you have to explicitly enable it.

With OpenGL, normal vectors have nothing to do with culling,
they are only used for lighting purposes; culling is determined
by the primitive vertices and the sign of the area they give
after projection to screen(ish) coordinates.


>
> Also, having trouble with with a dome composed of squares constructed
> similarly.
> No matter how the normal vectors are assigned, every square is culled
> when the viewpoint is inside the dome (the opposite is needed).
> Is OSG computing normal vectors after the app sets them?
>

No, OSG never computes normals for you.
For your dome you either need to swap the vertex order,
or change the culling mode:

http://www.opengl.org/sdk/docs/man/xhtml/glCullFace.xml

Can't recall the OSG equivalent at the mo, you'll have to look it up.


>// Normal vectors.
>const osg::Vec3f crossProduct = ((*vertexs)[0]) ^ ((*vertexs)[1]);
>

This is wrong. You are doing the crossproduct of 2 vertices, not 2 vectors.
You want:

osg::Vec3Array&  vx = *vertexs.get();
osg::Vec3fcrossProduct = (vx[2] - vx[1]) ^ (vx[1] - vx[0]);

The rest looks OK though.

Btw, the plural of vertex is vertices, not vertexs.

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

Re: [osg-users] Picking bug?

[Simon Hammett]

2009/12/3 Fred Smith 

> Hi,
>
> On one occasion I don't get two intersections, only one. That's the
> problem.
>
> I expect two intersections. One for the first triangle, one for the second.
> I get only one, for the second triangle, even though I picked the left
> triangle.
>
> You can easily reproduce this with the OSG file I listed.
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=20825#20825
>
>
This bug is due to the geometry being 2D and the actual intersection being
calculated w/ floats.

If you need a quick and dirty fix, you can change the code in

void TriangleIntersector::operator () (...)
 [[ src\osgUtil\LineSegmentIntersector.cpp ]]

To use doubles instead.


I was going to make a submission for that, but I've been busy and
this issue may benefit from a bit of discussion, rather than just changing
the code to use doubles.

Basically it boils down the fact that when the geometry is entirely 2d,
there is some code in
   bool LineSegmentIntersector::intersectAndClip(...)
which expands the bounding box, leaving it just  1e-4 across in the thin
direction.

When you have vertices out at larger coordinates (> ~4000) the
intersection code starts hitting numeric precision problems.

So you can either go with doubles, change the size of the expansion of
the bounding box (and then hit precision issues again at some point in the
future),
add some sort of approximate floating point compare code or maybe don't clip
the pick ray to the bounding box when there is 2D geometry.

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

Re: [osg-users] Triangle mesh looks like a silhouette with no surface detail.

[Simon Hammett]

2009/12/4 Ulrich Hertlein 

> On 4/12/09 4:42 AM, Ray Stamper wrote:
> > through the Delta3d api, which worked well enough but was limited to 2^16
> vertices.  I
> > wrote a class to make a Geode from .ply files, but they end up looking a
> little weird.
> > Geometrically, they are correct.  The problem is that they end up looking
> like
> > silhouettes.  No surface features can be seen.  I would guess this is
> because I set the
> > Geometry with one colour and had it set BIND_OVERALL.  All the
> DrawElements on the mesh
> > are osg::PrimitiveSet::TRIANGLES.  Basically I'm trying to figure out how
> to make the
> > faces subtly stand out a little more, without just picking random colours
> for each
> > face.  I would appreciate suggestions.
>
> This sounds like you might have the geometry but without any normals.  If
> this is the case
> you won't get any shading which can make it look flat.
>
> Cheers,
> /ulrich
>

Try running the smoothing visitor  on your model.
in osgUtil/SmoothingVisitor

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

Re: [osg-users] Animated Models

[Simon Hammett]

2009/12/4 J.P. Delport 

> Hi,
>
>
> Paul Martz wrote:
>
>> Danny Lesnik wrote:
>>
>>> How can I create animations within OSG models (similar to cessnafire.osg
>>> sample scene).?
>>> for example, how this file was created?
>>>
>>
>> Look at the OSG file in a text editor and see what nodes it uses.
>>   -Paul
>>
>
> Delta3D also has a particle system editor that you might be able to use.
>
> jp
>
> And the blender to osg exporter does animations:

http://projects.blender.org/projects/osgexport/

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

Re: [osg-users] Picking bug?

[Simon Hammett]

2009/12/4 J.P. Delport 

> Hi,
>
> have you checked what the members of the TriangleIntersection struct are? I
> think you must make them double too, this it where we had problems in some
> of our code.
>
> jp


Opps, yes they need changing as well.

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

Re: [osg-users] Picking bug?

[Simon Hammett]

2009/12/4 Fred Smith 

> Thanks for all your answers.
> Hitting a little bit of a problem in my understanding of the source code.
> If I change TriangleIntersection to use Vec3d and not Vec3:
>
>
> Code:
>
>TriangleIntersection(unsigned int index, const osg::Vec3d& normal,
> double r1, const osg::Vec3d* v1, double r2, const osg::Vec3d* v2, double r3,
> const osg::Vec3d* v3):
>_index(index),
>_normal(normal),
>_r1(r1),
>_v1(v1),
>_r2(r2),
>_v2(v2),
>_r3(r3),
>_v3(v3) {}
>

You're changing the wrong bit. You want the next struct down
TriangleIntersector

struct TriangleIntersector
{
osg::Vec3   _s; <<< change these
osg::Vec3   _d;
float   _length;

int _index;
float   _ratio;
bool_hit;


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

Re: [osg-users] Full list of dependencies

[Simon Hammett]

2009/12/6 Rizzen 

> Hi
>
> Where can I find the full list of dependencies required for OSG 2.8 and
> list of configuration options for building OSG libraries?
>
> Rizzen


osg itself doesn't have any dependencies, only the plugins do.

You'll have to run cmake and look through that for specifics, there
are too many plugins for it to be worth making a list and too many
config options as well.

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

Re: [osg-users] Picking bug?

[Simon Hammett]

2009/12/4 Fred Smith 

> Nope, it still doesn't work.
>
> Not my lucky day...
>
>
Hi Fred,

I've attached my modified version of LineSegmentIntersector.cpp
if you want to try that. It's from 2.8.2 but it should be ok with most
recent
versions.

If that doesn't work for you, you'll need to roll a version which does more
robust
floating point comparison:

http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm

-- 
http://www.ssTk.co.uk


LineSegmentIntersector.cpp
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] Picking bug?

[Simon Hammett]

2009/12/7 Fred Smith 

> It seems to be working pretty well for me with this change, thanks!
>
> Do you guys think this could be integrated into 2.9.6 or maybe a later
> version?
>
> I understand you are considering the integration of this feature as a
> runtime option.
>
> Thanks again for all your input,
>
> Fred
>
>
Well I would volunteer to do it, but I'm jammed for time till at least the
end of Jan.

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

Re: [osg-users] Trouble porting to vs2008, heap corruption

[Simon Hammett]

2009/12/10 Chris 'Xenon' Hanson 

> On 12/10/2009 12:00 AM, Andreas Goebel wrote:
> > Hi,
> > you get heap corruption on windows if (not only if, but if) you mix
> > different system libraries, static runtime and dynamic runtime, or debug
> > dlls and release dlls.
>
>   You can get it that way too.
>
> > Make really sure that your release build uses release libraries only,
> > and vice versa.
>
>   Usually the linker will yell and scream at you if you try to do this, so
> it usually
> doesn't happen accidentally and without the programmer knowing.
>

No it doesn't, symbol mangling isn't different between debug/release builds.
(though that might be a handy option)

You won't get linker errors unless you've got methods or functions
deffed in/out depending on your build config.

Maybe we should add some funcs to the OSG libs, based on the config
to stop beginners accidentally mixing builds.

Mind you the error message from mixing release/builds is different
from the OPs screen shot. It usually says something about a memory
block not being in the heap.

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

Re: [osg-users] Develop a scalable binary file format for native OSG scenes?

[Simon Hammett]

2009/12/10 Chris 'Xenon' Hanson 

> On 12/10/2009 10:27 AM, Robert Osfield wrote:
> > Or... just have the binary format extension be .osgb... :-)
>
>   For filesystem-management purposes, I know I'd prefer a .osgb extension.
> So much easier
> to grep and write scripts when you can assume the content based on the
> extension.
>
> ++vote
-- 
http://www.ssTk.co.uk
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Borland/Codegear C++ Builder

[Simon Hammett]

2009/12/14 Wouter Boelen 

> Hi,
>
> I just got the dubious honour of becoming the poor sap who has to test the
> viability of using OSG in an existing project. Trouble is, it's been written
> in Borland C++ builder (and uses VCL,...). And the OSG source isn't fully
> compatible with its quirks. To make matters worse, Borland uses a different
> binary format than Visual Studio (which we use on newer projects).
>
> Anyway, I guessed the first step would be to build the entire OSG library
> with C++ Builder 2007 (generated a makefile for the 2.9.5 source). For the
> past couple of hours I've been "correcting" minor build errors, but this one
> seems to demand some more knowledge of the source:
>

Ugh.

Code:

> Error E2451
> C:\Source\Libraries\OpenSceneGraph-2.9.5_BORLAND\src\osg\GraphicsContext.cpp
> 624: Undefined symbol 'iterator
> ' in function GraphicsContext::remove(Operation *)
>

Try adding:
typedef std::list< osg::ref_ptr >::iterator iterator;

to the public part of 'class OperationQueue' in

C:\Development\OpenSceneGraph-2.8.2\include\osg\OperationThread

Looking at the code I'm surprised it compiles in any other compiler.
Borland is correct; there is no OperationQueue::iterator as far as I can
tell.

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