[osg-users] osgboostpython has moved

[Jean-Sébastien Guay]

Hello,

Even though I have been inactive in the past 3 years, I wanted to inform 
anyone who might be interested. Since Google Code is closing down in 
less than a year 
(http://google-opensource.blogspot.ca/2015/03/farewell-to-google-code.html), 
I went ahead and moved my old pet project osgboostpython to github.


https://github.com/Skylark13/osgboostpython

I think if I had to do it again, the lua scripting Robert has been 
working on would be a much better base for python scripting support, and 
I would not try to wrap all of OSG but rather expose specific 
functionality which would be itself coded in C++. But if anyone is 
interested in what is there, it costs me nothing to keep the source 
available, so well, there it is.


I take this opportunity to mention that other projects which are / were 
part of the OSG ecosystem are still on Google Code, with no mention of 
them moving / having moved. Perhaps it would be good for someone to get 
in touch with their authors if they are not active on this mailing list 
anymore. Unless they are dead projects of course.


Some by Paul Martz
https://code.google.com/p/osgworks/
https://code.google.com/p/osgbullet/
https://code.google.com/p/osgqsg/
https://code.google.com/p/osgephemeris/ (not sure if this is now the 
official repo or if it's still at andesengineering...)


By Kim C. Bale and me (unfortunately I'm not admin, just committer, so I 
can't move it myself)

https://code.google.com/p/osgocean/

Some by Jeremy Moles
https://code.google.com/p/osgcairo/
https://code.google.com/p/osgpango/

Some by Wang Rui
https://code.google.com/p/osgmodeling/
https://code.google.com/p/osgenginebook/

And there are others, just search for OSG or OpenSceneGraph at 
code.google.com


Hope this helps,

J-S

--
__
Jean-Sebastien Guay  jean_...@videotron.ca
 https://whitestar02.entrydns.org/

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

Re: [osg-users] Not coding all the time? Running the West Highland Way tomorrow!

[Jean-Sébastien Guay]

I've been reading your running blog entries for a while now (since I was 
at CM-Labs).


It always struck me how you take a very scientific approach to running, 
trusting data instead of gut feelings or hearsay or whatever. I'm the 
same in my own hobbies too, and I thought I was obsessive but then I saw 
you had the same type of approach to your running. I guess we stay 
engineers, even in our hobbies, right? :-)


Good luck on your run!

J-S


On 20/06/2014 2:40 PM, Robert Osfield wrote:

As we are posting links... Here's my personal running blog, I posted
an article on my goals, splits and links to the timing companies
website that updates progress as we pass through the checkpoints on
route:

http://trossachstrailrunner.blogspot.co.uk/2014/06/how-to-follow-west-highland-way-race.html
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.anydns.com/

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

Re: [osg-users] Maya2osg?

[Jean-Sébastien Guay]

Hi Chris,

I think I was one of the last to use it seriously, apart from Javier 
Taibo (the main Maya2OSG developer). That was over 2 years ago when I 
was at CM-Labs. I don't know if they continued using it after I left. 
They may have switched to 3DSMax and so be using OSGExp (3DSMax plugin 
to export to OSG) exclusively.


I think I might have binaries lying around for Maya 2012 x64 but not 
2014. Let me know if you want those.


I don't recall it being hard to compile from source though. You plugged 
in the path to your Maya directory in CMake (the Maya install contains 
the SDK, at least the 2012 version did, so you had no additional SDK to 
install as opposed to 3DSMax) as well as the path to a 64-bit build of 
OSG of course, and it would generate the solution (make sure you 
generate for Visual Studio x64). The CMake INSTALL target would copy the 
plugin and related .mel scripts to the right place.


Then you would have to start Maya from a shell that had the OSG binaries 
on your PATH. This is what I had in a batch file called "start_maya.bat":


set PATH=C:\Work\contentpipeline\osg;%PATH%
cd /d C:\Tools\Autodesk\Maya2012\bin\
start "bob" /b maya.exe

(incidentally I have an almost-identical start_max.bat too :-) -- at 
that point we had artists using both in the company)


Hope this helps,

J-S

On 29/01/2014 4:54 PM, Chris Hanson wrote:

  Is anyone using Maya2osg?

http://maya2osg.sourceforge.net/

  It doesn't look like it has been real active in a few years, and I'm 
wondering if anyone has a binary build that would work with Maya 2014 
on Windows? I'd like to evaluate it without having to build it from 
source.


--
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com 
http://www.alphapixel.com/

Training . Consulting . Contracting
3D . Scene Graphs (Open Scene Graph/OSG) . OpenGL 2 . OpenGL 3 . 
OpenGL 4 . GLSL . OpenGL ES 1 . OpenGL ES 2 . OpenCL
Digital Imaging . GIS . GPS . osgEarth . Terrain . Telemetry . 
Cryptography . Digital Audio . LIDAR . Kinect . Embedded . Mobile . 
iPhone/iPad/iOS . Android
@alphapixel  facebook.com/alphapixel 
 (775) 623-PIXL [7495]



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



--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] Retrobooster trailer

[Jean-Sébastien Guay]

Hi Terry,


If you want to see some artsy OSG work, I got my new trailer done last week.

http://youtu.be/z9a2SYQtWcE

Yep, saw it and retweeted it. Great work!

J-S

--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] Source files and PDB's

[Jean-Sébastien Guay]

Hi Bram,

I don't think anything is preventing you from adding the project files 
that CMake generates into your own solution if you want to. It's not how 
we generally recommend people work with OSG but I think it should work. 
The projects contain all the relevant settings to build the libs (paths, 
defines, ...).


There's another way though: if you build OSG in either debug or release 
with symbols, and then link your project with those, you can then run 
your own project, go to the Modules window in Visual Studio, find the 
OSG libs, right-click them and go to "load symbols". Then you can load 
up osg/src/osgUtil/CullVisitor.cpp into Visual Studio and place a 
breakpoint in it and it should break (if that code is run of course).


Hope this helps,

J-S


On 03/07/2013 4:55 AM, Bram Vaessen wrote:

Nobody has any information or opinion about any of this???

To clarify: I just want to be able to set a breakpoint inside OSG because all I 
know is that the cull visitor sometimes starts to spit out errors (when it 
starts seems random) and I want to trace the first error.

Could anyone tell me anything that might help in any way?

thank you!

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





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




--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] Spamming errors, view breaks

[Jean-Sébastien Guay]

Hello Bram,


I have to admit I'm not very good at the whole setting up projects and 
debugging frameworks.
My first question would be:
In my projects I do not have the actual source code in my IDE. I just include 
the debug libraries and header files I think. I believe I used the permade 
ones. Could you give me some pointer on how I can 'link' the source code (which 
I also have) to the debug osg library in MS visual c++ 2010?


You should really either take a course (online or otherwise) or read 
about debugging in Visual Studio then. It's a really powerful debugger, 
but there are a lot of things you need to learn how to do with it.


I'm assuming you can run a debug version of your program (which I will 
also assume is linked to a debug version of OSG, for reasons that should 
be familiar to you). You should also have the .pdb files that come with 
the debug OSG binaries. If you have the source of the same version of 
OSG as the pre-built binaries, then while running your app in debug, put 
a breakpoint in your code somewhere (maybe where you call the OSG 
viewer's frame() method, for example). You should then be able to go to 
the "Modules" window in VS (find it in the Debug menu), and in that 
window, find the OSG DLLs. If it says "symbols loaded" next to the DLLs 
you're fine (which should happen if you put the .PDBs in the same 
directory as the DLLs). If not, right-click on them and click "load 
symbols" and it will give you a file dialog where you can go find and 
select the appropriate .PDB file(s) for the DLLs. From there, you should 
be able to step into OSG code (and VS will ask you where the source 
files are located) or simply open an OSG source file and place a 
breakpoint somewhere in the OSG code. You don't need to have the OSG 
source files in your own project or solution.


There are a lot of other things you can do to make your life simpler. 
For example, OSG (and most iterator-heavy code) is slow in debug when 
compiled with Visual Studio (to be precise, when linked to the debug 
VC++ runtime). You can compile OSG yourself in release but with 
debugging symbols enabled. Then it will be much faster, and you can 
still debug (almost) as in a debug build. But you don't want to ship 
those OSG DLLs to your clients, because they'll be much larger than the 
regular release ones. And if you build your own projects in release with 
symbols, then your clients could pretty easily reverse-engineer your 
code. So what you can do is make an alternate release-with-symbols 
target which you use in your development, and then when you're ready to 
make a build for your clients you build the regular release without 
symbols (of both OSG and your projects). While you're at it, your final 
release build of OSG should disable OSG's notify handlers (it's an 
option in CMake when building OSG) which makes it faster - for some 
reason on Windows the OSG notify handlers slow down OSG a bit even when 
no messages are being output, and every little bit of performance helps.


Hope this helps,

J-S

--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] Spamming errors, view breaks

[Jean-Sébastien Guay]

Hello again Bram,


I am walking around in my world and sometimes suddenly I only see an empty 
screen and I the console spams messages like these:

CullVisitor::apply(Geode&) detected NaN,
 depth=-1.#IND, center=(64 64 18.2729),
 matrix={
 1.#QNAN 1.#QNAN 1.#QNAN 1.#QNAN
 1.#QNAN 1.#QNAN 1.#QNAN 1.#QNAN
 1.#QNAN 1.#QNAN 1.#QNAN 1.#QNAN
 1.#QNAN 1.#QNAN 1.#QNAN 1.#QNAN
}

Now I can't seem to find any action that triggers it always, seems kinda 
random. Also the program continues so I can't seem to find a way to debug it.

Anyone had these kind of errors before? What could be the problem and how could 
I make the program break on these errors so I can debug the problem?


What you should do is simply break in your debugger when this happens. 
To do this you need an OSG build with symbols, and set a breakpoint 
where that message is printed in the OSG source, then run in your 
debugger. You can then walk the scene graph from the Geode that caused 
the problem up to where it originated (normally a MatrixTransform higher 
up in the graph).


In non-final builds you could try to trap NANs at the source (for 
example, wrap any calls that set OSG matrices in your own code, and have 
that code trap NANs before passing them to OSG).


Hope this helps,

J-S

--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] Viewer default fov settings

[Jean-Sébastien Guay]

Hello Bram,


Thanks yeah, I actually had screenWidth/screenHeight there and they were 
correct, but were also ints
I changed it to 16.f/9.f and now it seems to work.

I'm still unclear about what happens if you divide ints
I had

int screenWidth = 1280;
int screenHeight = 720;


This is the same as for all C/C++ code... diving ints does whole 
division, so 1280/720=1


Cast each to float before the division and you'll be fine.

 (float)screenWidth / (float)screenHeight

J-S

--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] Viewer default fov settings

[Jean-Sébastien Guay]

Hello Bram,

The key observation is this:


but I get a streched out view in the horizonal direction, as if a 1:1 image is 
streched onto a 16:9.


What are 1:1 and 16:9? They are aspect ratios. The documentation for 
osg::Camera::SetProjectionMatrixAsPerspective() here:


http://trac.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a00073.html#fe4fab17f1cc5b4664c17ed79717aabb

says that the first argument is the fovy (vertical FOV) and the second 
is the aspect ratio, which will in turn define what the horizontal FOV 
is. You are passing an aspect ratio of 1.0 unconditionally. If you want 
the aspect ratio to be natural, you cannot just pass 1.0, you need to 
pass your viewport (or window) width/height.


Hope this helps,

J-S


On 26/05/2013 11:00 AM, Bram Vaessen wrote:

Hi,

I recently changed from just setting up a viewer


Code:
viewer->setUpViewInWindow(500,300,1280,720,1);



To making a custom camera, but I can't seem to get the same 'normal' view as I 
did in the default viewer camera.

I use:

osg::ref_ptr camera = new osg::Camera();
camera->setViewport(new osg::Viewport(0,0,screenWidth,screenHeight));
camera->setProjectionMatrixAsPerspective(30.0, 1.0, 0.5, 1000);

but I get a streched out view in the horizonal direction, as if a 1:1 image is 
streched onto a 16:9.

I tried looking into the code for viewer and viewerbase, and view, but it was 
getting a little too much. Hopefully someone has a good idea on what the 
default setup is and why I'm getting a streched out view.

Thank you!

Cheers,
Bram

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





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




--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] loading of a large number of files

[Jean-Sébastien Guay]

Hello Lucie,

The issue is I use a wrapper c++ to c# to create a window with osgviewer in a 
WPF application and the application throws an unhandled exception, I haven't 
other informations on the exception.


In the Visual Studio GUI you can go to Debug -> Exceptions and check all 
exceptions, this will make the debugger break when an exception is 
thrown and not when it is caught. This may help you pinpoint what's 
going on.


Unfortunately in some cases you can't run all the time with this enabled 
because some apps (particularly in C#) throw exceptions in 
non-exceptional circumstances... Bleh... So if it's possible you may 
have to start your app, then enable all exceptions in that dialog, and 
then trigger whatever causes the exception.


Hope this helps,

J-S

--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] anyone have experience with OSG on Intel HD Graphics 4000 hardware?

[Jean-Sébastien Guay]

Hi Terry,


Looks like a very cool resource. Have you ever been able to put it to
any practical use? I could see this being helpful, but I don't see it
removing all of the randomness :) There are always undiscovered bugs
lurking here and there. I, too, would love to see driver writers
aiming for 100% scores on these tests.


I think for now the main use is that it publicizes the quality of the 
different drivers. However as I said, it would be much more effective if 
it were used in an "official" manner, i.e. by Khronos itself.


I now work for a game company where we explicitly blacklist some driver 
versions and inform the user to upgrade when the game starts up, because 
some driver versions are just too bad to be any use at all. I could see 
something like that being part of an add-on library to OSG, where a 
database of driver versions and capabilities would be maintained by the 
community. With the breadth of coverage that's possible in a large 
community like OSG, I think it would be easy, actually :-) That being 
said, I don't have any plans to actually do something, rather than talk 
about it :-)


J-S

--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] anyone have experience with OSG on Intel HD Graphics 4000 hardware?

[Jean-Sébastien Guay]

Hi Terry, all,


In short,
good luck understanding the insane mess that is graphics drivers. It's
all very random.


It's only random if you try to understand it with a few limited 
tests :-)


Someone has applied structured testing to the problem and has come up 
with this:


http://www.g-truc.net/post-0538.html#menu

This is the "OpenGL driver status" posts, which Christophe Riccio posts 
every month. He gathers this information using his own very 
comprehensive OpenGL tests, which cover about every type of 
functionality you would want to use in a very structured way. So he can 
say with absolute certainty that a given driver will work with a given 
usage pattern. (I wish this were used as a base for official Desktop 
OpenGL conformance tests and that the results of these tests were 
publicised by Khronos, so that vendors would have a real reason to keep 
their drivers up to a certain level of quality... But I digress)


Then you just have to know your own app enough to know what it's doing 
at the OpenGL level... Which is often the hard part :-) Tools like 
gDEBugger (discontinued) or apitrace (active) can help there.


The only thing I find a pity is that he doesn't keep an easy to search 
list of older drivers too. If he did, you could easily see that a given 
feature worked starting with this version, broke in this one and then 
was fixed in this one, and you could tell that to your clients, knowing 
which features are critical to your application. You could even 
automatically enable and disable features in your app by knowing which 
driver versions they would work on. But maybe that's going too far...


Anyways, it's a useful resource I think.

J-S

--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] Shadow Volumes integration

[Jean-Sébastien Guay]

Hi John,

One suggestion, you could use nested namespaces, and then abbreviate 
locally so it's easier to read. For example:



namespace osgShadow
{
namespace ShadowVolume
{
class Occluder { ... }
}
}

// then in some .cpp file where you need to use it:

namespace osgsv = osgShadow::ShadowVolume;

void someFunction()
{
osg::ref_ptr occluder = new osgsv::Occluder;
}

That way we don't need a new separate "top-level" namespace, it shows 
it's clearly a shadow technique so it's in osgShadow, yet it's separate 
from the other osgShadow code so you prevent name clashes. And using the 
abbreviated name locally helps with code that would become really 
verbose and hard to read, while not being ambiguous like "using 
namespace ..." in the case some classes have the same name eventually.


Just a suggestion, I don't know if Robert will like this style, he may 
prefer one of your other suggestions but this is another alternative to 
add to the mix.


J-S


On 31/01/2013 5:21 AM, PCJohn wrote:

Hi,

me and my coleague have developed number of Shadow Volume shadow algorithms
and we would like to contribute them one day to OSG.

To mention the reason for Shadow Volumes: They are often used in CAD, etc. as
they work in screen space, thus they do not suffer with aliasing/resolution
problems of Shadow Map-based algorithms. Surely, you pay the quality by the
speed. But sometimes, you simply can not tolerate shadow artifacts and
performance of shadow volumes on today graphics cards is basically excellent
(in my eyes).

My questions (probably on Robert) to best fit with OSG design:

- My implementation covers number of methods (7-10 planned, 2 in developement,
4 finished) starting from simple cpu implementations and finishing by geometry
shader and OpenCL implementations (silhouette based approaches). Thus I have
family of classes like Occluder, OccluderGroup, ShadowDataBuilder,
CpuSilhouetteDataBuilder, OpenCLSilhouetteOccluder (12 at the moment, and
more on the way). I was considering to append them to osgShadow library, but I
am worrying about some name clashes as, for instance, "Occluder" or
"ShadowDataBuilder" are too general names and developers of Shadow Maps might
(1) want to use them or (2) they might cause some confusion as there is
already, for instance, OccluderGeometry class.

Would you prefer to:
(a) do not worry about clashes and simply use Occluder name as it is still not
in use in osgShadow (the same with all other classes).
(b) to create namespace osgShadowVolume and make ecosystem of classes of
shadow maps and shadow volumes distinct - they really does not have much in
common and probably only share just two abstract base classes:
osgShadow::ShadowedScene and osgShadow::ShadowTechnique. Having two separate
namespaces may make even doc more understandable because when looking for a
particular class, I will look into the appropriate namespace and not to the
mix of both shadow approaches.
(c) prepend Occluder by a prefix SV, e.g. SVOccluder, SVOccluderGroup
(d) prepend Occluder by ShadowVolume prefix, e.g. ShadowVolumeOccluder,
ShadowVolumeVertexExtrusionDataBuilder,
ShadowVolumeGeometryShader2DManifoldSilhouetteOccluder. I am just not sure if
some names would not lost readability - 4 words in class name seems acceptable
to me but adding two more seems too much. And surely, I would need to think
how to make the longest names a little bit shorter - the last class still does
not exist, but its full name would not be acceptable.
(e) postpone the decision

I am refactoring my code now so any suggestions welcomed.
John

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




--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] Integration of a NodeKit for Sky Rendering

[Jean-Sébastien Guay]

Nice work Daniel, results look great!

In the past I have used osgEphemeris, which supports sky sphere, sun, 
moon, stars based on earth latitude/longitude and date/time. It gave OK 
results but had a few problems as well. Its site is 
www.andesengineering.com/Projects/*OsgEphemeris*/ but it seems to be 
down at the moment.


Just out of curiosity, how flexible is your library? For example, a long 
time ago I had to develop a lunar rover simulator, and I was able to 
easily use osgEphemeris' night-time sky (replacing the moon by a larger 
Earth, of course, and I didn't mind about exact positions of the stars ) 
to make the lunar sky. See the end of this video for an example: 
http://www.youtube.com/watch?v=b1tN2TpVIOM   Is something like this easy 
with your library?


Keep up the great work!

J-S


On 18/01/2013 10:13 AM, Limberger, Daniel wrote:


*From:*Limberger, Daniel
*Sent:* 18 January 2013 15:50
*To:* Engel, Juri
*Subject:* Integration of a NodeKit for Sky Rendering into OSG

Hi,

I would like to present you my open source library osgHimmel that 
allows simple noninvasive rendering of background imagery (i.e., 
skies) within OSG. It currently is an OSG extending lib, that features 
two different techniques for sky rendering (or in traditional terms, 
skybox rendering): texture based (traditional) and computational 
(astrophysical).


The first approach handles rendering of skies via common texture 
mapping techniques, extended by time based transitions, rotation 
around the zenith, horizon blending as well as an (experimental) faked 
sun.


The second approach, renders astrophysical based skies with good 
results not only but especially at nightly scenes: correct star 
positions, atmosphere approximation, moon rendering including lunar 
eclipses and more.


Further Contributions to OSG:

-A useful, minimal astronomy library.

-Good resources for both, texture based and physical based, approaches.

-Solutions for common OSG issues, e.g., placing skies in arbitrary 
node structures, texture ping-ponging for post/pre processing, 
environment map rendering for reflection/illumination.


-Starting point for cloud rendering. The current implementation is not 
very efficient though (TODO..)


-Introduces no third parties, purely based on OSG (and optionally Qt 
for the editor)!


For now, osgHimmel is mainly used internally at the Computer Graphics 
Systems group at the HPI (hpi3d.de), and the first integration into a 
commercial product is already in progress. We have two research 
projects, trying to extend the library by HDR, temporal-glare, Glare, 
simple as well as image based illumination.


I would like to suggest an integration of osgHimmel into OSG, since a 
larger user base would convince me to keep osgHimmel alive and spent 
further development time on the library.


What requirements must be met and what further steps have to be taken 
to make this integration possible (we can rename the lib to osgSky if 
this is a problem ;) )?


Or is it better practice for such library to stay independent, without 
a direct OSG integration?


I'm strongly interested in any ideas and concerns of this community 
concerning osgHimmel.


All resources (including videos, demos, poster, my master's thesis, 
and a recent vmv2012 paper) are available at:


http://osghimmel.googlecode.com

recent poster with some images: 
https://osghimmel.googlecode.com/files/Daniel_Limberger_Poster.pdf


Thanks a lot! And also thanks to this mailing list, which was of great 
help during development of osghimmel.




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



--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] osgmovie receive stream

[Jean-Sébastien Guay]

Hello David, Wang Rui,

Personally I haven't tested how to load rtsp/udp video streams using 
osgdb_ffmpeg directly.


I have used the ffmpeg plugin with an IP webcam that only supported rtsp 
feed, and it worked well (I made some submissions to make it work back 
then, it should still work).


Hope this helps,

J-S

--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] lighting of pointsprites

[Jean-Sébastien Guay]

Hello Daniel,


I know  I can do my own thing by implementing a shader program, but first I 
wonder if there is a limitation for point sprites to not beeing able to be 
illuminated by default.


Actually, the only way to get point sprites to be lit is to use a 
shader. Think about it, a point sprite is just a point which is expanded 
to a polygon in view space. So it has no normals, or at most it has a 
single normal which points in the wrong direction (the point's normal), 
duplicated for all vertices.


In a shader, you can choose to make your point sprite have sphere 
normals, or any other shape you want. You can also use a normal map to 
get an even better shape. The fixed pipeline cannot do this. Fixed 
pipeline point sprites were designed for simple billboarded sprites.


Hope this helps,

J-S

--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] Retrobooster playable demo

[Jean-Sébastien Guay]

Hi Terry,

A little more blatant self-promotion here. I just released the first 
playable demo of my OSG-based game. Check it out if you want to see 
some crazy OSG action. 
http://www.reallyslick.com/retrobooster/downloads.html


Great work! It really looks like a game where you need to practice to 
get better, which I love. Graphically I love your particle effects (the 
rotation with movement and all), the lighting on weapon impact, the way 
the ship's thrust effect changes when you take damage, etc. Lots of 
little things that show your attention to detail.


My kids loved to find new and brutal ways to destroy the ship and/or 
kill the little people. I guess that's one kind of emergent gameplay you 
might not have planned for... :-)


About the multi-screen issues Jan mentioned, I didn't have any problem 
like that on Windows 7 x64. Looks like SDL's handling of multi-screen 
setups is inconsistent indeed. Any reason you didn't do your own 
windowing based on GraphicsWindowWin32 and GraphicsWindowX11? You might 
have more control that way. Using SDL for sound and input doesn't force 
you to use it for windowing too...


Good luck for the eventual release of the full game!

J-S

--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] Orbit manipulator right and middle mouse movement speed

[Jean-Sébastien Guay]

Hello Janna,


Currently I've created sub classes based on current manipulators in osgGA such 
as OrbitManipulator however I think it would be great to submit small patched 
to osg later.


I think that's generally a good idea as it means you have less code to 
maintain on your side in the future, and others may benefit from your 
changes as well.



I've seen something interesting in the code related to NodeTrackerManipulator 
[...]


This is something related to the Vortex integration of OSG, so I think 
we should take this off-list. Not that it's necessarily sensitive 
information, it's just not useful to others on this list.


J-S

--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] Orbit manipulator right and middle mouse movement speed

[Jean-Sébastien Guay]

Hello Janna,


Is there particular reason scale is hard-coded and no parameter is exposed to 
be able to modify movement scale for middle and right mouse button? Or is there 
some other way to do it?


There was a large refactoring of camera manipulators about 2 years ago. 
OrbitManipulator is one of the camera manipulators that were added 
during that process, so it's relatively recent in OSG. As such, I 
suspect the reason is simply the standard open-source development one: 
no one in the past has yet needed to change these values, so they were 
not exposed.


There are two options worth considering IMHO:

- The methods are virtual, you can subclass OrbitManipulator and do what 
you want, even add tweakable parameters with setters/getters and use 
them in the overridden version of the methods.
- Modify the OSG sources to expose new parameters, submit the change and 
use that once it's integrated.


There are a few cases when I was at CM-Labs where I did both: I 
subclassed to get the behavior I wanted right away (and test that it 
really worked in our applications) while at the same time submitting a 
code change to OSG to do the same thing. Once the change was integrated 
into OSG and we had moved to this new version that included it, I could 
remove the subclassed version in our code to avoid having to maintain 
that code in our own code-base. There were more than a few cases where 
subsequent discussion on this list led to me refactoring or improving my 
change beyond what I would have done if it had stayed in our code. This 
kind of collaboration really benefits everyone.


Hope this helps,

J-S

--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] nVidia bug with multiple windows

[Jean-Sébastien Guay]

Hi Bradley,

Good detective work on getting a minimal repro example.

In the past, I've reported a few driver bugs to devsupp...@nvidia.com 
and gotten pretty quick responses. I encourage you to submit your 
example to them, just make sure you include all necessary DLLs so they 
can run it. They will be able to fix it with just a binary repro 
example, they don't need source.


Good luck,

J-S


On 16/10/2012 2:50 PM, Bradley Baker Searles wrote:

Hi,

Short Version

Run the attached files with the osgCamera example on your nVidia Geforce GPU (we're on 
Windows), with the parameters "-s -3 [FILENAME]". You'll notice the file 
1_UV.OSG renders the single triangle fine. 2_UV.OSG does not render correctly across the 
windows (it  added only a second UV set).

Has anyone else seen this and have any other solutions or workarounds, other 
than enabling VBO and/or multi-threaded viewer?

Long Version

We've identified an issue with nVidia Geforce hardware and geometry with 
multiple UV sets when being displayed on multiple windows. This may be a driver 
bug, as we don't see it on Intel or AMD GPUs (or interestingly, an nVidia 
Quadro in a laptop here), but there are some interesting details.

I've narrowed the problem down to an OSG file containing a single triangle, and 
I can reproduce the issue in the osgCamera example. I will attach the minimal 
example files.

The issue only seems to appear in the single threaded viewer model. When running with the 
parameters "-s -3" in osgCamera, we get the following behavior:

1_UV.OSG - Single triangle with one texture, one UV set. Works fine.

2_UV.OSG - Same as above, but added one additional UV set. Initially it was 
another texture added as well, but that is unnecessary to generate the problem. 
Triangle only renders in one of the spawned windows.

2_UV_VBO.OSG - Same as 2_UV.OSG, but with VBO turned on. Renders fine across 
all windows.

So the two workarounds we've found so far is to enable VBO on all geometry, or 
enable the multi-threaded viewer.

Using VBO across the board does give us a performance hit in our application, 
from 5% to 35% depending on the scene being rendered and the GPU/Driver combo 
(including Intel and AMD).

When we first enabled it on our OSG Composite Viewer, the multi-threaded mode was set, 
but "startThreading" was never called (we're creating our own windows, so 
realize is not called). Interestingly, this seems to have made the geometry corruption 
issue go away even though the additional threads were not spawned... Enabling the 
multi-threaded viewer properly has caused some other misbehavior in our app, but we may 
be able to work around the problems.

Platform:
Windows 7 x64
16 GB RAM
nVidia 680, driver 306.97 (we've tried back to 275.33 with a 460 board)
OSG 3.0.0 via VS 2010 SP1
Two monitors (so my osgCamera example spawns across them both, although we've 
reproduced the issues on a single monitor machine).

Any help, suggestions, or commiseration would be appreciated :)

Thanks!
Baker Searles

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




Attachments:
http://forum.openscenegraph.org//files/20121016_nvidia_multi_context_render_corruption_191.zip


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




--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] Ideas about a resource system, and deferred rendering framework

[Jean-Sébastien Guay]

Hi Jeremy,

Is there a term for this kind of approach? Well "impostors" comes to 
mind. That's where you would replace a complex mesh by a quad with a 
texture representing the complex mesh. Then when some criteria changes 
significantly (orientation of the view to the object, light source 
position, etc) you would re-render the texture once to fit the new 
criteria. This can be useful for far away meshes, for example trees 
where a close mesh is used, then lower and lower LODs, and eventually 
just a quad with a texture. Impostors are used so that the texture is 
still dynamic, instead of just a static billboard (which tend to look 
obviously like static billboards).


Hope this helps,

J-S


On 11/09/2012 10:19 AM, Jeremy Moles wrote:

On Tue, 2012-09-11 at 10:54 +0800, Wang Rui wrote:

Hi Jeremy,

Thanks for the tests and feedback. I'm focusing on creating a material
system which may be a little similar to the Ogre one but will be very
easy to integrate with OSG scenes. I'd like to also have a benchmark
including a complete deferred shading pipeline in the near future to
show others how OSG produces realistic worlds. :-)

Your requirement could be easiliy implemented with one forward pass
rendering the scene to a texture, and two deferred passes doing the
blur work with the texture as input. A final compositing pass will
make use of the outputs of the blur passes and output to a new
texture. You can get and use the new texture then in the scene for
your own purpose instead of direct displaying them on screen. I'd like
to upload a DOF effect file and an updated example some days later to
demonstrate how these work.

Are there ever cases, when doing sophisticated layering of rendering
like this, that you'd want to manually "kick off" the EffectCompositor
for just a single frame and update the texture only once? (For example,
by setting the NodeMask to 0xF for one frame, then back to 0x0 when
you're done updating the View).

Is there a term for this kind of approach, and would it make sense to
also support this model of rendering directly or should it be left up to
the user?


Thanks,

Wang Rui

2012/9/11 Jeremy Moles :

On Mon, 2012-09-10 at 22:57 +0800, Wang Rui wrote:
This looks really cool so far. I'd be really interested to know if it
supports the following (and would be willing to create examples if
you're willing to help)...

Scenario: I want to render an entire subgraph to an FBO texture once,
then apply 2 or more completely different shaders in some order, then
put the final result into a last texture to be used somewhere in the
scene. I'm doing a guassian blur, which typically applies two different
shaders for x and y.

I have this working in osgPPU, but I think you already have enough to do
it here, I just couldn't put the pieces together. :)


___
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




--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] Osg + Maya status?

[Jean-Sébastien Guay]

Hello Per,

I would recommend exporting to .osg instead of .ive when you come to 
export with maya2osg, since the .osg format is text it is generally 
compatible across many OSG versions unlike .ive which is binary.


Try to generate solutions for maya2osg using cmake, I think that will 
work better, perhaps the checked-in solutions are not maintained 
anymore. I always used solutions I generated myself using cmake.


Hope this helps,

J-S


On 07/09/2012 4:39 AM, Per Nordqvist wrote:

Haha, whatever you say :-)

My pipeline is more complicated, since I have existing .3ds + .ive
files I need to update in Maya,
then export back to my application.
For the import to maya I'm looking at the FBX format, for the export
I'll probably need the
osgmaya plugin to get full control.

My application (based on OSG 3.01) is not integrated with maya, so I'm
free to use whatever
OSG version for the plugin as long as the final exported .ive files work.
I have tested compiling against 2.8.3 and 3.01 without success so far,
but only with the existing solution file.
I can't find 2.9.x on the osg website. Might be I have to use svn to
get hold of it.

I'll try some more with cmake and maybe talk to Javier about it. I'll
post here if there is some progress.

Thanks again J-S, impressive that you find the time to help us all.

/Per


On 7 September 2012 01:21, Jean-Sébastien Guay  wrote:

Hello Per,

There is no such thing as noise for the OSG list, especially not when it's
so directly related to a project in the OSG ecosystem. It's totally relevant
and will be useful to someone else I'm sure. So I'm putting this back on the
list :-)

I didn't go from any pre-existing solution file, I just generated my own
with maya2osg's cmake build system (similar to OSG's own).

IIRC, I built maya2osgwith an OSG off the SVN trunk, probably close to 3.0.
It's been a while though (at my previous employer which I left over 9 months
ago) so depending on whether your OSG version is more or less recent it may
or may not compile. In that case, you can probably collaborate with Javier
Taibo and / or "PP" (Peter Particle I think it stood for) who were active
developers of the project back then and probably still monitor this list.
You can also subscribe to its own mailing list at

https://lists.sourceforge.net/lists/listinfo/maya2osg-users

though I think they are on both so they should see these messages too.

Another thing I remember, I would compile maya2osg with an SVN trunk version
of OSG, but the models exported from maya in .osg format would read fine in
an OSG 2.8.3 viewer. So that's what we did, since our own software needed to
use a "stable" / released / numbered version of OSG, not OSG from SVN). Our
pipeline looked like this:

1. Create models in maya
2. Export with maya2osg (compiled against OSG 2.9.x or whatever) in .osg
format
3. Optimize the .osg model and save it as .ive using a custom tool based on
osgconv (built using OSG 2.8.3, so the binary .ive format was compatible
with our software)
4. Use the .ive or the unoptimized .osg in our software (built using OSG
2.8.3)

So as I see it you have 2 options depending on the version of OSG you were
using to build maya2osg:

1. If it was a recent version (3.1 and up, or current SVN trunk) I'm sure
the maya2osg folks will want to update the plugin to build against that
version, so you can try to make it work and submit the changes to them or
talk to them to see if they're willing to do it.
2. If it was an older version, for example the version you need to build
your own software with, you could adopt a pipeline like the one I outlined
above.

As an alternative to option 2, you could also modify maya2osg to compile
against that version of OSG (using #ifdefs with the OSG version to make sure
you don't break its compilation against newer versions). But I think that
might make the code very messy, so the maya2osg folks might not accept to
merge those changes back in, which I think is understandable, and then you'd
be left with having to maintain your own private fork of the plugin...

Hope this helps,

J-S



On 06/09/2012 10:49 AM, Per Nordqvist wrote:

Hi J-S, thanks for responding. I assume you started from the Maya 2011
solution,
with Visual Studio 2008?
Im trying to compile now but I'm probably using the wrong version of OSG,
getting lots of API related errors during compile time.
Do you remember which version of OSG you used that matches Maya 2011?

(I'm posting off the list to reduce the noise. If I succeed I'll post
the conclusions there)

/Per

On 6 September 2012 12:45, Jean-Sébastien Guay 
wrote:

Hello Per,

I've used Maya2osg with Maya 2012 x64. I compiled the plugin myself
though.

J-S



On 06/09/2012 3:22 AM, Per Nordqvist wrote:

Hi all,

I'm trying to find a working pipeline between osg 3.01 & Maya 2013.
I started with intermediate f

Re: [osg-users] Osg + Maya status?

[Jean-Sébastien Guay]

Hello Per,

There is no such thing as noise for the OSG list, especially not when 
it's so directly related to a project in the OSG ecosystem. It's totally 
relevant and will be useful to someone else I'm sure. So I'm putting 
this back on the list :-)


I didn't go from any pre-existing solution file, I just generated my own 
with maya2osg's cmake build system (similar to OSG's own).


IIRC, I built maya2osgwith an OSG off the SVN trunk, probably close to 
3.0. It's been a while though (at my previous employer which I left over 
9 months ago) so depending on whether your OSG version is more or less 
recent it may or may not compile. In that case, you can probably 
collaborate with Javier Taibo and / or "PP" (Peter Particle I think it 
stood for) who were active developers of the project back then and 
probably still monitor this list. You can also subscribe to its own 
mailing list at


https://lists.sourceforge.net/lists/listinfo/maya2osg-users

though I think they are on both so they should see these messages too.

Another thing I remember, I would compile maya2osg with an SVN trunk 
version of OSG, but the models exported from maya in .osg format would 
read fine in an OSG 2.8.3 viewer. So that's what we did, since our own 
software needed to use a "stable" / released / numbered version of OSG, 
not OSG from SVN). Our pipeline looked like this:


1. Create models in maya
2. Export with maya2osg (compiled against OSG 2.9.x or whatever) in .osg 
format
3. Optimize the .osg model and save it as .ive using a custom tool based 
on osgconv (built using OSG 2.8.3, so the binary .ive format was 
compatible with our software)
4. Use the .ive or the unoptimized .osg in our software (built using OSG 
2.8.3)


So as I see it you have 2 options depending on the version of OSG you 
were using to build maya2osg:


1. If it was a recent version (3.1 and up, or current SVN trunk) I'm 
sure the maya2osg folks will want to update the plugin to build against 
that version, so you can try to make it work and submit the changes to 
them or talk to them to see if they're willing to do it.
2. If it was an older version, for example the version you need to build 
your own software with, you could adopt a pipeline like the one I 
outlined above.


As an alternative to option 2, you could also modify maya2osg to compile 
against that version of OSG (using #ifdefs with the OSG version to make 
sure you don't break its compilation against newer versions). But I 
think that might make the code very messy, so the maya2osg folks might 
not accept to merge those changes back in, which I think is 
understandable, and then you'd be left with having to maintain your own 
private fork of the plugin...


Hope this helps,

J-S


On 06/09/2012 10:49 AM, Per Nordqvist wrote:

Hi J-S, thanks for responding. I assume you started from the Maya 2011 solution,
with Visual Studio 2008?
Im trying to compile now but I'm probably using the wrong version of OSG,
getting lots of API related errors during compile time.
Do you remember which version of OSG you used that matches Maya 2011?

(I'm posting off the list to reduce the noise. If I succeed I'll post
the conclusions there)

/Per

On 6 September 2012 12:45, Jean-Sébastien Guay  wrote:

Hello Per,

I've used Maya2osg with Maya 2012 x64. I compiled the plugin myself though.

J-S



On 06/09/2012 3:22 AM, Per Nordqvist wrote:

Hi all,

I'm trying to find a working pipeline between osg 3.01 & Maya 2013.
I started with intermediate formats (3ds, flt, obj) but no joy,
material settings are all messed up.

Now I am looking at the native osgMaya:
http://maya2osg.sourceforge.net/
but it only supports older version of Maya, i.e 2009/10/11.

Has there been any efforts on this plugin for Maya 2013?

Thanks,

/Per Nordqvist

p.s. the community page
http://www.openscenegraph.org/projects/osg/wiki/Community/Plugins
points to http://www.diosoft.com/soft/osgmaya/ but this page seems dead.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



--
__
Jean-Sebastien Guay  jean_...@videotron.ca
 http://whitestar02.dyndns-web.com/

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



--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] Osg + Maya status?

[Jean-Sébastien Guay]

Hello Per,

I've used Maya2osg with Maya 2012 x64. I compiled the plugin myself though.

J-S


On 06/09/2012 3:22 AM, Per Nordqvist wrote:

Hi all,

I'm trying to find a working pipeline between osg 3.01 & Maya 2013.
I started with intermediate formats (3ds, flt, obj) but no joy,
material settings are all messed up.

Now I am looking at the native osgMaya:
http://maya2osg.sourceforge.net/
but it only supports older version of Maya, i.e 2009/10/11.

Has there been any efforts on this plugin for Maya 2013?

Thanks,

/Per Nordqvist

p.s. the community page
http://www.openscenegraph.org/projects/osg/wiki/Community/Plugins
points to http://www.diosoft.com/soft/osgmaya/ but this page seems dead.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] Custom Drawable & GLSL

[Jean-Sébastien Guay]

Hi Jeremy,

In the past I've done similar low-level 2-pass rendering in a Drawable, 
by doing as Robert suggests. Apply one stateset, draw, apply another, 
draw again (same or different geometry).


A Program is just state, so you need to draw something in between 
setting different Programs. Otherwise setting the first Program has no 
(visible) effect. I know it sounds obvious but I thought I'd just throw 
that out there so there's no ambiguity :-)


Hope this helps,

J-S


On 04/09/2012 1:23 PM, Jeremy Moles wrote:

On Tue, 2012-09-04 at 11:05 -0600, Paul Martz wrote:

Doesn't a Drawable's state get applied prior to the call to
Drawable::drawImplementation()? If so, you could just put the _program in your
Drawable's StateSet?

I'm working on a nodekit for NV_path_rendering, which takes an "as of
yet unseen" approach to rendering; new go OpenGL, at any rate. :)

They call it the "Stencil then Cover" approach, and like most 2D vector
drawing libraries, there is a notion of both STROKING _and_ FILLING. In
order to support arbitrary shading on both the affected stroke fragments
and affected fill fragments, I need to be able to potentially set two
different shaders during a single drawable drawImplementation.

Now, having said that--which I potentially should have mentioned in the
first email--does that change any advice you might have? :)

(Thanks for the response, btw... good info.)


It's easy to verify that things are happening in the right order using a
debugger with breakpoints set at your drawImplementation() and also at
Program::apply().

If it doesn't happen as I describe above, then I believe what you're doing below
is the most robust, as that code would work with all other rendering in the
scene graph, both shader and non-shader rendering.

Honestly it's been too long since I played at this level. But I seem to recall
that the difference between:
  _program->apply( state );
and
  state->apply( _program.get() );
is that the latter tracks the currently bound program, doesn't bother to apply
it if it's already in use, and would probably allow you to remove the call to
setLastAppliedProgramObject(0).
 -Paul


On 9/4/2012 9:58 AM, Jeremy Moles wrote:

I am creating a custom Drawable that needs to push a Fragment Shader
into the current rendering state and then, after a single extension
call, subsequently remove this shader from the state.

I have some code I noodled through to make this work, but I feel like
there is probably a better way. It goes something like this:



drawImplementaion(RenderInfo&  ri) {
State* state = ri.getState();
unsigned int contextID = state->getContextID();

_program.apply(state);

myExtensions->doMycall();

GL2Extensions::Get(contextID, true)->glUseProgram(0);

state->setLastAppliedProgramObject(0);
}



Like I said above, this "works", but I feel like there is probably a
cleaner way to achieve what I want. Note that _program is a ref_ptr to a
properly create osg::Program object, since I certainly do NOT want to
recreate all the goodness it provides. :)

Any API advice?

___
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




--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] Safe downcast

[Jean-Sébastien Guay]

Hello,

For the answer, I suggest you revise the C++ docs about dynamic_cast<> 
and also check the class hierarchy of OSG's node types.


dynamic_cast succeeds for any pointer to an object of class A or any 
pointer to an object of a derived class of A. So even if you don't have 
a proper Group at the root, if you have any object of a derived class of 
Group (like osg::MatrixTransform, osg::Switch, etc.) it will succeed.


Check out Node::asGroup() (reimplemented in osg::Group) for an 
alternative to dynamic_cast (trades a dynamic_cast which is pretty 
costly for a virtual method call which is much less costly).


Hope this helps,

J-S

On 21/08/2012 3:49 PM, Peterakos wrote:

Hello.

I forgot to mention that i check it. That's why i posted it. Cause it 
is very strange to run even though there is no group as root..


osg::ref_ptr node = 
dynamic_cast(osgDB::readNodeFile( "astroboy_walk.dae" ));

if(!node) {
   std::cout << "Model could not be loaded " << std::endl;
   return 1;
}

thank you.


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



--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] Extensions/State Update Question

[Jean-Sébastien Guay]

Hi Jeremy, nice to see you back writing graphics code!

In the past, when I've needed to have a contextID in a custom Drawable, 
I've always gotten it from inside my drawable's drawImplementation. IIRC 
it gets a State pointer and this contains a valid contextID. Same when 
I've needed to create a custom StateAttribute or something, in its 
apply() method it gets a State pointer with a valid contextID or 
something like that.


So you can have a scheme where you defer doing any initialization until 
your first Drawable / StateAttribute needs to be traversed for actual 
rendering, and then you get a valid contextID, do your initialization 
and further ones will use that since initialization has been done already.


You need to make sure you consider the case where your Drawable / 
StateAttribute will be used in multiple contexts. IIRC OSG uses the 
BufferedValue to store resources associated with a context, and I used 
the same pattern. Again IIRC, there were some order of initialization 
issues where I assumed some initialization had been done for a context 
before drawing but it hadn't, but that just involved a bit of pretty 
simple debugging to get fixed.


Hope this helps,

J-S


On 20/08/2012 12:48 PM, Jeremy Moles wrote:

On Mon, 2012-08-20 at 10:44 -0600, Paul Martz wrote:

What you seem to be saying is that you want to set some OpenGL state once that
applies to all contexts, and not have to set it every frame. AND, you don't want
to have to add, then remove, a Camera draw callback just to make this happen).
Is that a good synopsis of the issue?

It's close; I don't actually mind using a Camera draw callback for this
purpose if it's appropriate.

A real summarizing question is: under what conditions is it "safe" to
query for support of a particular extension? And what is the preferred
API for either fetching or being provided the contextID with which to do
this?


You could keep a bool buffered_value that tells you whether or not you've set
the initial/global state for that particular context. Initially false, then set
the global state for a context and flip it to true. Would something like that 
help?
 -Paul

Certainly, but I'm still stuck on actually SETTING the state in the
first place. :)


On 8/20/2012 10:27 AM, Jeremy Moles wrote:

Hello everyone! I have a bit of a strange question here, so please bear
with me. I'll try to be as descriptive as I possibly can, though I'm
certain I will misuse some terminology.

I am adding support for the NV_path_rendering extension to
OpenSceneGraph. This extension adds a number of new functions to OpenGL
when using an NVidia card which take on the form:

glPath{_function_}NV

http://osgnvpr.googlecode.com

In order to create pointers to these new extension functions, I create
an Extensions object in OSG using the contextID given to me during the
compileGLObjects method of my overridden Drawable class. This works
fine, and the code is running as I expect.

https://code.google.com/p/osgnvpr/source/browse/trunk/src/PathCommands.cpp#45

HOWEVER, this paradigm really only works when I need to call extension
functions associated with an instance (or instances) of my Drawable.
There are other functions in the NV_path_rendering API that simply set
global state, and it is with these functions that I'm having difficulty.

The biggest problem here is that in order to get a pointer to the
Extensions static object, I need a valid GraphicsContext contextID.
However, I've tried a number of methods to obtain one of these, but
every attempt I make actually breaks the entire codebase. I wish I could
explain it better than that...

For example, if I try to use some code like the following:



Windows windows;

viewer.getWindows(window);

cID = windows[0]->getState()->getContextID();

osgNVPR::getNVPRExtensions(cID);

-

...then I seem to get an invalid contextID and all subsequent attempts
to use that contextID (even by OSG itself) won't work. The entire
rendering process seems to be broken in this manner.

If instead I create a Camera::DrawCallback object and use the RenderInfo
there instead, then everything works fine. However, I feel like I'm
grossly misusing a Camera::DrawCallback just to set and unset state...

My question is: if I need to set global state like this once, somewhere
high in the scenegraph, what is the best way--keeping in mind that I
also need a valid contextID in order to access my Extensions functions
per-context?

Thanks!

___
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://lis

Re: [osg-users] Repository broken with SVN >=1.7.5?

[Jean-Sébastien Guay]

Hi Robert,

Looks like you just made a small typo, you need one colon not two:

Not

svn proget svn::externals .

but

svn proget svn:externals .


Hope this helps,

J-S


On 18/08/2012 5:09 AM, Robert Osfield wrote:

Hi Ulrich,

I've just done a 'svn proget svn::externals .' in my check out of the
OSG in the same way you have suggested and don't get any matches.  I
am using svn, version 1.6.17.

The OSG used to pull in OpenThreads but these days OpenThreads is
directly part of the OSG reposity and it's the external OpenThreads
build that pulls in from OpenSceneGraph to get it's source code.  OSG
users shouldn't ever need to build OpenThreads as a separate project.

Robert.

On 18 August 2012 05:24, Ulrich Hertlein  wrote:

Hi guys,

ever since updating my Subversion client to 1.7.x I've been getting errors 
regarding
OpenThreads when updating:

$ svn up
Updating '.':
svn: warning: W20: Error handling externals definition for 
'include/OpenThreads':
svn: warning: W17: URL
'http://www.openscenegraph.org/svn/osg/OpenThreads/trunk/include/OpenThreads' 
at revision
13110 doesn't exist
svn: warning: W20: Error handling externals definition for 
'src/OpenThreads':
svn: warning: W17: URL
'http://www.openscenegraph.org/svn/osg/OpenThreads/trunk/src/OpenThreads' at 
revision
13110 doesn't exist
At revision 13110.
svn: E205011: Failure occurred processing one or more externals definitions

After doing a clean check-out I'm not getting src/OpenThreads and 
include/OpenThreads anymore.

src/OpenThreads and include/OpenThreads are pulled in via svn:externals 
references to the
OpenThreads repository:

$ cd OpenSceneGraph
$ svn propget svn:externals .
include/OpenThreads
http://www.openscenegraph.org/svn/osg/OpenThreads/trunk/include/OpenThreads
src/OpenThreads 
http://www.openscenegraph.org/svn/osg/OpenThreads/trunk/src/OpenThreads

Which would be fine, except that OpenThreads in turn has external references to
OpenSceneGraph!

$ cd OpenThreads
$ svn propget svn:externals .
include/OpenThreads
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/include/OpenThreads
src/OpenThreads 
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/src/OpenThreads

So we have a nice (or rather not so nice) circular reference and the newer SVN 
clients
apparently don't deal with this.

To solve this I suggest to remove the 'svn:external' on the OpenSceneGraph base 
directory.

Or am I the only one still using the SVN repository?
Should I turn off the lights and move on?

To my knowledge the hg and git repositories are not official and only mirror 
the SVN
repository?

Cheers,
/ulrich
___
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




--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] OSG application onMicrosoft Surfface table?

[Jean-Sébastien Guay]

Hi Helen,

I've seen some applications using WPF for their GUI and rendering OSG 
into a widget. Essentially you can embed OSG into a widget given its 
HWND. I don't remember the details so you may have to look around and do 
some testing on your own.


On the other hand, if this tech really restricts the technologies that 
can display onto it, then it may well prevent C++ applications from 
running (in favor of C#) or prevent OpenGL applications from running at 
all. This you'll have to discover on your own. The wonders of being an 
early adopter! :-)


In addition, some discussion took place before concerning OSG and 
multi-touch interfaces, I think some development was done to enable this 
(in particular for iOS and Android) so multi-touch should be possible in 
the general sense, but I don't know whether that piece of hardware uses 
standard protocols to send touch events to applications or if it's a 
Microsoft-specific thing (probably the latter). Again, you'll have to do 
some testing, and maybe some modifications to OSG to enable multi-touch 
on this device.


Hope this helps,

J-S


On 16/08/2012 6:36 AM, Helen Wang wrote:

Hi,

We recently bought a  Samsung SUR40 with Microsoft PixelSense.

We would like to migrate a current exsiting OSG application to this multi-touch 
surface table.

However, after some quick exploration, it seems this is a very tricky task 
because its Microsoft Surface SDK 2.0 only supports the development using WPF 
and XNA.

Is it possible to migrate OSG applications to Microsfot surface table at all?

Does anyone have any experience of developing applications using OSG on the 
multi-touch surface table?

Looking forward to your advice!
  
Thank you!


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





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




--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] ESC key: Error: pthread_cond_destroy(, ) returned error status, status = 16

[Jean-Sébastien Guay]

On 04/08/2012 2:38 PM, Alberto Luaces wrote:

I think if you write an osgGA::GUIEventHandler that reports that you
handled the ESC key (by returning true), the viewer won't do its own
processing.


In addition to this, I suggest you look into the following methods of 
the osgViewer::ViewerBase class (which both CompositeViewer and Viewer 
inherit):


/** Set the key event that the viewer checks on each frame to 
see if the viewer's done flag should be set to

  * signal end of viewers main loop.
  * Default value is Escape (osgGA::GUIEVentAdapter::KEY_Escape).
  * Setting to 0 switches off the feature.*/
void setKeyEventSetsDone(int key) { _keyEventSetsDone = key; }
/** get the key event that the viewer checks on each frame to 
see if the viewer's done flag.*/

int getKeyEventSetsDone() const { return _keyEventSetsDone; }
/** if the flag is true, the viewer set its done flag when a 
QUIT_APPLICATION is received, false disables this feature */

void setQuitEventSetsDone(bool flag) { _quitEventSetsDone = flag; }
/** @return true if the viewer respond to the 
QUIT_APPLICATION-event */

bool getQuitEventSetsDone() const { return _quitEventSetsDone; }

Hope this helps,

J-S

--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] SimLab Composer

[Jean-Sébastien Guay]

Hi John,

On 01/08/2012 12:08 PM, John Richardson wrote:
AhWill behave in the future. Thanks for explaining the threading. 
Even though I think I am starting a new message by just erasing the  
subject line it has some sort of residual internal ID. This probably 
happened with all the BOF postings.


Exactly, there is a thread ID in the message headers which stays set 
even if you change the subject line. Most mail clients and forum 
gateways use this rather than the subject as it's more reliable.


Thanks for understanding :-)

J-S

--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] SimLab Composer

[Jean-Sébastien Guay]

Hi John,

I think you're creating a little confusion on the OSG list and forum at 
the moment. I've noticed the last few times you posted, it was as a 
reply to a thread, but your message didn't have anything to do with the 
thread you were replying to.


Many mail readers, and the forum (which is a mirror of the mailing list) 
use thread ID to put messages into threads. When you reply to a message, 
your message gets the same thread ID as the message you replied to, so 
it gets put into the same thread (as a reply, which makes sense) but 
your message doesn't relate at all to the message you were replying to, 
so the person who wrote the original message is confused about your reply.


Also people who were meant to see your message might not. For instance, 
some people only read the forum, and your message will not be a 
top-level post but a reply to another thread which they might not read.


So in the future I suggest you start a new thread (by writing a new 
mail) instead of replying to an existing thread. This should be just a 
few keystrokes more than replying, since your mail client most probably 
has the OSG mailing list address already memorized and will probably 
fill it in when you type "osg" in the To: field. But it will save a lot 
of confusion, and will ensure your post is seen by all.


Robert, this should probably be an FAQ, I've seen others do the same 
thing in the recent past. (do we have an FAQ for the mailing list? if 
not we should)


Thanks,

J-S


On 31/07/2012 1:24 PM, John Richardson wrote:

Hello,

Just ran across this in a CAD newsletter.

SimLab Composer: Apparently, this imports and exports OSG. Also, it seems to
import a lot of other file formats. So, it is theoretically, an authoring
tool suitable for OSG authoring and conversion. No experience on the
correctness of exports and scene building capabilities. Just noticing the
import and export features which are in the least expensive version.

USD99 --> USD249 [Macintosh and Windows]

www.simlab-soft.com

John F. Richardson


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



--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/

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

Re: [osg-users] 3D Modeler for OpenScenegraph

[Jean-Sébastien Guay]

Hello Andrea,


Do you think Blender can do that?


Not only Blender, but 3D Studio Max, Maya, Softimage XSI, genrally all 
3D modeling software will allow you to organize your scene in terms of 
groups, transforms (of which DOF is one specialization), LOD and so on.


Then the question becomes, how do I import the models created in these 
software tools in such a way that this hierarchy makes it into the OSG 
program?


Have a look at a post I just wrote that talks about this. The thread is 
called "Which model format to use? FBX vs. VRML". In a nutshell, there 
are native plugins for Max, Maya and Blender (maybe others too) which 
export the scene from these programs directly into native .osg format, 
and these will generally preserve as much of the scene hierarchy as they 
can.


So then my advice is, choose whichever tool your artists / content 
creation people want to use, and then start using the OSG plugin for 
that tool. If the plugin has some shortcomings (for example last I used 
it the Maya plugin maya2osg didn't support LOD nodes) then work with the 
authors to help implement the missing feature. Open source at its best!


Hope this helps,

J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/


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

Re: [osg-users] [osgPlugins] Which model format to use? FBX vs. VRML

[Jean-Sébastien Guay]

Hello,


I hope to use either FBX or VRML models. What are the pros and cons
of each model?


I will echo Jan's suggestions and add a bit more info.

VRML support is pretty bad in current content creation tools (I've 
tested with Max and Maya primarily). The problem is mostly the way 
things are represented is different for each tool's exported VRML, and 
the amount of things in your scene that will make it into OSG is pretty low.


FBX is a bit better I have found. Both Max and Maya's exported FBX files 
have pretty good coverage of what is in your scene, and the OSG FBX 
loader is pretty good (and its primary author Michael Platings has been 
very responsive in the past, though it's been a while since I've seen 
him post on the list).


Jan's suggestion to go with a native exporter is spot-on. the Max 
exporter osgExp is very good, as is the Maya exporter osg2maya (just 
google those names). Their authors are (or have been) regular posters on 
this list, so bugs or things broken by changes in OSG's API (though 
infrequent) are normally quickly fixed. And the advantage of getting an 
OSG file directly is very interesting, you can write scripts that will 
add information to nodes directly in Max and things like that.


Essentially, this advantage is huge. You go directly from Max or Maya to 
.osg format, there is no intermediate format in between where 
information can get lost in the conversion... Whoever makes the models 
in Max or Maya has much better control over how their work will look in 
the final application, because the translation is direct, there's no 
need to figure out by trial and error which feature is not supported 
that makes it look like that and how to work around these limitations.


Hope this helps,

J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/


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

Re: [osg-users] osgWidget Frame borders

[Jean-Sébastien Guay]

Hello Jason,


There are pixel gaps in between the corners and borders that make the frame 
look quite awful. I am guessing there are some ever so slight rounding errors 
when computing the quad locations.


Most often, borders like that come from the default wrapping mode OpenGL 
uses on textures, which is CLAMP_TO_BORDER. The default border color is 
black, and for the last pixel in linear interpolation mode OpenGL will 
interpolate between the last pixel of the texture and the border color, 
so you get a gray color there.


You should set it to CLAMP_TO_EDGE instead (this really should have been 
the default from the start), which will make OpenGL interpolate between 
the last pixel and itself, so no border will show. Now, if this is when 
using osgWidget then it's probably osgWidget loading the images, not 
you. So you might have to modify osgWidget (and submit the modification 
:-) )


I think I've used border images like that but always with dark or 
semi-transparent images, so the border just didn't show in my testing... 
Otherwise I would have fixed this! :-)


Hope this helps,

J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/


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

Re: [osg-users] [forum] how to store the picture of every frame to buffer more quickly?

[Jean-Sébastien Guay]

Hello Yi Lin,


my question is : how to store the picture of every frame to buffer more quickly?


Essentially, readPixels() stalls the frame until the whole pipeline is 
flushed, then reads the framebuffer. This is what introduces the 
slowdown you see. What you would want in order to make this faster is to 
defer reading the framebuffer to the GPU, so it can read it when it 
makes sense to do so and so not stall.


I'm not sure (I can't remember the specifics) but I think either 
ScreenCaptureHandler or WindowCaptureCallback have a path to use 
double-buffered PBOs to read the framebuffer. This is what you should 
use. The result you get will be one frame late, but at least it will be 
faster (won't stall the GPU as readPixels would).


Hope this helps,

J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Get data from color buffer

[Jean-Sébastien Guay]

Hello Nicolas,


The second thing I tried is to use a ScreenCaptureHandler. What I did worked 
for each frame, but the image is directly stored as an image on the hard drive. 
Is it possible to save it as an osg::Image?


I think ScreenCaptureHandler will do what you want. It has support for 
setting a CaptureOperation (the default CaptureOperation is a 
WriteToFile, see osgViewer/ViewerEventHandlers and search for 
ScreenCaptureHandler and CaptureOperation and WriteToFile).


So you can create a class that inherits CaptureOperation and overrides 
the operator()(const osg::Image& image, const unsigned int context_id) 
method to do whatever you want with the const osg::Image& that is passed 
to the method. Then you set that as your ScreenCaptureHandler's capture 
operation using setCaptureOperation(CaptureOperation* operation).


Hope this helps,

J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Nvidia Optimus / AMD switchable

[Jean-Sébastien Guay]

Hi Brad,


I am looking at getting a couple of laptops with Nvidias 'Optimus'
switchable graphics and AMDs equivalent.

My hope is to be able to manually switch between the two so I can test
our application using both discrete and Intel graphics. There was a
thread back in September of last year which didn’t sound too encouraging.

Can anyone provide any feedback on the current state of these
technologies when running OSG based applications?


The last time I tested this, the latest NVidia Verde driver behaved 
pretty well. Essentially, the driver lets you select between 
"auto-switch or manual switch" but these are misnomers. They should be 
called "behavior-guided and profile-guided" switching.


When on "auto-switch", the driver tries to detect usage of a 3D API and 
switch to discrete graphics. This seems to work well for Direct3D 
programs, and for some OpenGL programs, but our own applications would 
create an offscreen context to detect hardware features and then create 
another context for the actual application, and this "auto-switching" 
seemed to switch just a bit too late, which meant that the detection 
would detect the integrated graphics, turn off a bunch of features, 
possibly even create some OpenGL objects on the integrated graphics and 
then switch to the discrete graphics, with dire consequences.


The manual switch means that you need to create a profile for your 
application. In the profile (which just matches you app's exe filename), 
you tell it whether it should run on the discrete graphics or the 
integrated graphics. Note that adding a profile works in "auto-switch" 
mode too, meaning the profile will override the behavior detection.


But making a profile (or telling all your users to make a profile) might 
be a hurdle you don't want for your app. If the auto-switch mode works 
well enough, just use that.


There's a third mode, which is to force using the discrete graphics, the 
integrated graphics, or Optimus in the BIOS. We ended up using only 
discrete graphics in the BIOS, because we didn't want to deal with the 
other modes.


It's been a while since I tested this. Hopefully newer drivers improve 
this situation. Let us know in any case.


Hope this helps,

J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Advice for placing large number of objects on grocery shelves ?

[Jean-Sébastien Guay]

Hello Maia,


One solution would be to place everything in a modeler and export as a whole 
but we need to interact  (i.e. pick) with some objects on the shelves.


This is the best option I think. The simplest solution is to create the 
shelves and objects in a modeling program, name the objects 
appropriately, and then in your OSG program write a simple NodeVisitor 
that will give you pointers to each object you want by traversing the 
loaded scene and checking the object names. Then you can selectlvely 
make objects interactive, enabling you to move the objects your user 
will be picking for example.


Hope this helps,

J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Loading OSG resources from Qt QResource system

[Jean-Sébastien Guay]

Hi Martin,


has anyone tried loading textures, meshes etc from the Qt resource system? I am 
thinking about how best to distribute my resources with my application.


I have loaded meshes (in .osg format) from Qt resources in the past, yes.

In general as long as the plugin you want can accept a binary or text 
istream (depending on whether it's a text or binary format) to load 
from, it should work. If the plugin only implements loading using a 
filename, you'd have to write the resource to a temp directory and load 
it from there.


Hope this helps,

J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Building new website, assistance appreciated!

[Jean-Sébastien Guay]

Hi Michael,


I'm not sure About is suitable for Showcase. Gallery is more about
Showcase. About is more about OSG, not some related projects. And
Gallery is... a gallery of what have been done with OSG.


I disagree. I meant Showcase to be about "selling" OSG. Meaning, when 
someone stumbles on the OSG site and wonders if OSG would be good for 
their project, they'll see Showcase in the About menu and will 
immediately see what OSG is capable of. Gallery is more a place where 
the community can show what they've done, so more exhaustive. It's more 
about people showing what they've done than people seeing what can be done.


But you may be right, I may be seeing a difference where there is none. 
It may not be a good idea, it may duplicate things.


J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Building new website, assistance appreciated!

[Jean-Sébastien Guay]

Hi Jordi,


@J-S I picked up your suggestions and I just added download->
tools/data/dependencies. About showcase menu item I already have a
similiar item in community->Derived Software, but if you feel it's worth
to have it in About I will go ahead with this change.


I don't have a specific preference on where the info should be, but I 
think there are two specific goals here:


1) Give links to any software based on OSG, so people who want to use 
nodekits or engines based on OSG can find them, this seems to fit 
Community - Derived Software


2) Promote the best OSG projects to show what OSG can do, I think this 
would be nice in About - Showcase


My motivation for number 2 is that in the past, I have had trouble 
convincing people that OSG was a good tool for the job. People were 
inclined to think game engines (Ogre, Unreal) or other scene graphs 
(Vega Prime) gave better results because there are clear examples of 
projects that have used those and got good results. So I think it's 
important to have a place where we can promote that OSG is a first-class 
graphics engine and can do all the really advanced effects when in 
capable hands.


A gallery and derived software section is not the right place for that, 
because we'll often want to list any/all projects there, whereas in a 
Showcase section we can pick and choose to try and put the best face 
possible for potential new users.


People who stumble upon OSG when looking for a graphics engine will 
probably look at the About section before the Community section, because 
they are first interested in whether OSG can fit their purposes, and 
realize the benefit of the large community later. So to make a good 
first impression, I think we need a section in About that will show what 
can be done with OSG.


Just my two cents,

J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Building new website, assistance appreciated!

[Jean-Sébastien Guay]

Hi Jordi,


The vast majority of the articles does not have information yet, but I
am filling them step by step. If you see something that I missed or
something that could be improved or better categorized say it! :). It's
very important to do this before to fill all the contents, it's the way
to get the information quick.


I really like the menu at the top. Much better than the old Trac menu at 
the right side... The top-level items are good IMHO, and apart from 
adding a few other items in some menus, I think the contents of each 
menu are good too.


Specifically, I would add:

* About - Showcase (or some other term)
A page that would link to projects done using OSG (whether they're 
downloadable / open source or not). I would sub-categorize this page in 
1) engines / frameworks based on OSG, 2) vis-sim applications / 
simulators, 3) games. As we've seen in recent threads, I think OSG 
doesn't have enough visibility and showing successful projects done 
using OSG would promote it greatly.


* Downloads - Tools
A page with links to the major exporters (OSGExp for 3DSMax, 
Maya2OSG for Maya, Cedric's Blender plugin, etc.), modeling tools 
(OSGEdit, Remograph), etc. that people can use in conjunction with OSG.


* Downloads - Data
People often come to the list/forum asking where they can find free 
data. Of course the sample datasets would be listed here. Also some 
links to the Google sketchup model library (mentioning that they can 
load .kml using a specific plugin, was it collada?), and other free / 
open source model libraries would help them on their way.




Apart from my own suggestions, I think you should perhaps start a new 
thread, in order to get more focused comments. Specifically target 
people who have just started using / learning OSG, or who have just 
installed it and are in the process of looking over the documentation / 
examples. Ask them how they found the existing documentation. I think 
Robert was suggesting a change in the structure of the documentation, 
don't remember what it was, but I'm pretty sure new users will have good 
ideas and comments on what works and doesn't work in the current 
structure. This will prevent you from doing things the same way as on 
openscenegraph.org, if it's not that effective for new users...


Great work so far, keep it up!

J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [ANN] OpenSceneGraph 3 Cookbook Published!

[Jean-Sébastien Guay]

Hi John,


And , just to check that you are reading to the end of the email.


Hah, made me look, again!


A copy of Rui’s and Xuelei’s book was given away at last year’s SIGGRAPH
OSG BOF [WOW – lots of acronyms]


Actually four copies! Thanks to Wang Rui for donating them.

It was a (not very scientific/pseudo-random) draw of business cards/torn 
pieces of paper. Thanks to whatever lottery regulation authorities exist 
in BC for not having been there! And thanks to the attendees for their 
patience while I tried to draw the names and be fair to everyone...


J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [ANN] OpenSceneGraph 3 Cookbook Published!

[Jean-Sébastien Guay]

Congrats Wang Rui, great work, I look forward to reading it!

J-S


On 01/04/2012 2:40 AM, Wang Rui wrote:

Hi all,

First of all, this is NOT a joke on April Fool's Day. :-)

I'm glad to announce the publication of the book OpenSceneGraph 3.0
Cookbook, which is yet another OSG book written by me, with the help of
Dr. Qian Xuelei. Thanks to my technique reviewers: Torben Dannhauer,
Vincent Bourdier, and Chris Hanson. Also many thanks to Robert Osfield
and the whole OSG community!

Exactly 100 recipes are introduced in this book (some may not appear in
any of the pages because of the page count limitation, please refer to
the source code repo). You should be familiar with the basic concepts of
the OpenSceneGraph API before reading this book as it includes some
advanced techniques like a initial deferred shading implementation,
quick integration with physics engines, and so on. There are totally 9
chapters focusing on different fields, including the installation,
nodes, geometries, camera manipulating, animations, effects, terrain
building, data management, GUI integration, and a bonus chapter which is
removed from the book content because of the too high page count but
added as a free sample chapter on the Packt website.

You can buy the book at the Packt Publishing website:
http://www.packtpub.com/openscenegrap-3-for-advanced-3d-programming-using-api-cookbook/book


and/or Amazon.co.uk :
http://www.amazon.co.uk/OpenSceneGraph-3-Cookbook-R-Wang/dp/184951688X

The source code can be downloaded freely at:
https://github.com/xarray/osgRecipes

Cheers,

Wang Rui



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



--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Passing dae data in shader.

[Jean-Sébastien Guay]

Hi Christian,


I would think that modifying the reader might be easier than
processing its generated output.


I would say the opposite - creating a NodeVisitor that you run over the 
loaded graph, which will massage the data to suit your needs, would be 
easier than modifying the reader plugin. The NodeVisitor you can write 
knowing only OSG and OpenGL. The reader plugin you need to also know the 
source format and idiosyncracies of it, which in the case of DAE could 
be opening a whole can of worms.


As an added benefit, you can even write your NodeVisitor such that it 
will be as general as you want. It could be able to post-process any 
loaded scene graph, independently of the original format, because it 
takes as input any OSG graph. Whereas modifying the reader would give 
you the expected result only with one file format; if you want to get 
the same results with another format you need to re-do all your 
modifications in that other reader plugin...


In the past I've written a NodeVisitor that eventually gave data 
structures renderable in DirectX, and in pure OpenGL without using OSG 
as the render backend. Writing such a visitor is not too hard, and it's 
easy to debug too.


Hope this helps,

J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Falling off the NVidia fast path

[Jean-Sébastien Guay]

Hi Chris,


   I just wanted to follow up and note that GL_RGBA16 seems to have been
the culprit. GL_RGBA16F_ARB performs fine.


Have a look at this. It's an older version of the NVidia GPU programming 
guide, but it (and the newer version at the following link) has lots of 
good info.


http://developer.download.nvidia.com/GPU_Programming_Guide/GPU_Programming_Guide.pdf

http://developer.nvidia.com/nvidia-gpu-programming-guide

In the Supported Texture Formats section, you will see that the 
A16B16G16R16 format (which is GL_RGBA16 in OpenGL land) is not supported 
on GeForce 6 and 7 cards, but A16B16G16R16F (GL_RGBA16F_ARB) is.


I also found this document:

http://developer.nvidia.com/content/nvidia-opengl-texture-formats

It states that RGBA16 is internally substituted by RGBA8 in all nvidia 
chipsets that support it, so I wouldn't use it anyways even on cards 
where it is supported. Whereas RGBA16F (which seems to be named 
FLOAT_RGBA16 in the left-most column) is supported natively since NV30 
(GeForce FX). This is commonly called a half-float format BTW.


If you want exact values to carry over from your program into your 
shaders, you might still want a non-float format. From the G80 chipsets 
onward it seems like you can use RGBA16UI (RGBA16UI_EXT) through the 
EXT_texture_integer extension. The above texture format table seems to 
have lots of good info to decide what to use in your specific use case, 
and here's the link to the extension in question.


http://developer.download.nvidia.com/opengl/specs/GL_EXT_texture_integer.txt

Hope this helps,

J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgShadow and multitexture

[Jean-Sébastien Guay]

Hi Wojtek,


This should be no problem for models with more
texture stages as long as you substitute shadow technique shaders with
your own set which can process your multiple textures correctly.


Almost correct - the problem is that the shadow technique also disable 
all shaders for the shadow pass. So even if the models / scene provide 
shaders which do multitexturing, the shadow pass will only alpha blend / 
alpha test with the texture in unit 0 when rendering the shadow pass.


A shader could be set with OVERRIDE mode in the graph, and then (IIRC) 
it will be used during the shadow pass. I'd have to check the code again 
to confirm that the disabling is not done with PROTECTED mode...


J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Hiding a node from a single view

[Jean-Sébastien Guay]

Hi Don,


What is the best way to accomplish this?  Node masks, cull callbacks?


Chris's solution will work fine, but you may have many objects you want 
to control independently and then you'll run out of bits in your node mask.


If that's the case, a cull callback can be another way to do it. In a 
cull callback, you can dynamic_cast the nodevisitor pointer to an 
osgUtil::CullVisitor, then get the current camera and its view. If you 
have any way of identifying the nodes you want to see and the ones you 
don't, and the views in which you want them to be visible or not 
(something as simple as a string comparison to the name of the 
node/view, or a hash map lookup, or whatever) then in the cull callback 
you can simply not traverse and that node's children (geometry etc) will 
not be visible.


You could get fancy and implement your own "PerViewSwitch" node, that 
would inherit from osg::Group and override the traverse() method to 
decide whether to traverse or not based on the name of the 
view/camera/node or whatever.


Hope this helps,

J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Issues with RotateCylinderDragger

[Jean-Sébastien Guay]

Hi Chuck,


I tracked down the problem.  It seems that the original code tried to come up 
with a plane parallel to the cylinder axis oriented towards the eye/pick point. 
 This calculation breaks down when the eye and cylinder axis are close to being 
parallel.  I have fixed the problem and will be submitting a patch within the 
next day.  I am trying to go through the code to do more cleanup as the 
original has a number of code paths that are never reached.


I think there was a submission fixing this not too long ago. Which 
version of OSG are you using? It may be worth looking at the most recent 
code for RotateCylinderDragger in svn, and perhaps testing a build of 
OSG svn just to make sure you're not doing work that has already been done.


J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgVolume RayTracedTechnique problem

[Jean-Sébastien Guay]

Hello Clement,


One of the machines is using Intel E8300 Du e core 2.83 cpu with using on 
board graphic.  Another XP machine I created by virtual machine.


You're kind of setting yourself up for problems trying to get an 
"advanced" technique like GPU ray tracing working on onboard graphics or 
the emulation in a virtual machine. IIRC recent versions of VirtualBox 
and maybe others can route OpenGL calls to the driver on the host 
machine, but last I checked there were still bugs and most complex apps 
I tried (complex being defined as more than simple GL test programs) had 
some problem or other.


As soon as you get into shaders and recent graphics features, try to 
have the prerequisites (a good video card, recent drivers) and you'll 
have much less problems.


Hope this helps,

J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Stitching together sphere geometry in OpenSceneGraph

[Jean-Sébastien Guay]

Hello Preet,


* The issue I've run into involves where my 2D texture wraps around
and meets itself on the sphere:
http://i.imgur.com/ftVH2.png


I don't think there's anything wrong with your geometry and texcoords. 
Good work!


The problem looks like you may be using the default texture wrap mode, 
which is CLAMP. This mode can also be called "clamp to border", which 
when texture coordinates run outside the range of 0-1 will give a border 
color, which defaults to black. The problem is that when the texture 
coordinates are exactly 0 or 1, when you have linear interpolation 
enabled as filter mode (again the default), then the border color will 
still get sampled (since it's trying to filter using that texel and the 
one next to it, which is outside the 0-1 range). So you get those black 
lines around your textures.


Try to specify the CLAMP_TO_EDGE wrap mode instead. This will simply 
sample the same texel at the border and should eliminate the black line.


Hope this helps,

J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.1.0 dev release tagged

[Jean-Sébastien Guay]

Hi Robert,


I'm afraid I
can't think of all the headline changes in 3.1, been a bit too long in
coming I'm afraid - over six months since 3.0.1.


Well, for one there's the new ViewDependentShadowMap which greatly 
improves shadow stability over the previous 
LightSpacePerspectiveShadowMap technique and also lays the foundation 
for better support for multiple shadow maps per light source and shadows 
cast by multiple light sources.


(Thanks a lot for all your hard work on that technique once again)

J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgUtil::Optimizer and osgSim::DOFTransform with data variance STATIC

[Jean-Sébastien Guay]

Hi Magnus,


But maybe this question is more to the authors of osgmaxexporter. Why
does osgmaxexporter unconditionally set the data variance to STATIC?
What are the use cases where one would model a STATIC DOFTransform?


DOFTransforms are a relic of Multigen (Presagis) Creator, and in that 
software they were the most widely used transform node. Modelers (as you 
probably know) are fond of putting lots of transforms (and groups) all 
over the scene graph, to keep things understandable to them, and to make 
it easier to modify the model later.


Unfortunately, there are often many of these transforms that aren't 
really useful once the models are in the simulation software. So yes, 
there is a valid use case for static DOFTransforms - transforms that 
were just put there by the modeler for convenience, but which don't have 
any use in simulation.


Now, I agree with you, the STATIC data variance should not be 
unconditionally applied. There can be rules to determine when it should 
be, for example if the DOFTransform does not have any limits.


At my previous employer, we had made a custom osgconv which would 
"massage" the scene graph before calling the osgUtil::Optimizer on it (I 
think I mentioned this before on this list). This "massage" is highly 
dependent on what you'll be doing with your data, which is why I don't 
think it would be useful to submit such a thing - OSG provides the tools 
for you to do the right thing in your situation. But just as an example, 
our tool would:


* Normalize state to expected values (we didn't require artists to set 
the right filtering or face culling manually, we enforced it in the 
tools, so that osgUtil::Optimizer's various merge operations could give 
good results)
* Flag nodes as dynamic if we didn't want them optimized away (we had 
various rules, including if a comment contained "Dynamic", if a DOF had 
limits, etc.
* Remove most Group nodes since these just hinder the merge visitors and 
in most cases, better batching (less draw calls) is more important than 
better spatial culling.


Again, I've talked about these things in the past, and others have 
shared similar or related advice too.


Hope this helps,

J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [ANN] OpenSceneGraph 3.0 Cookbook: ready for pre-order and code tests

[Jean-Sébastien Guay]

Congrats Wang Rui!

I wish you great success with this new book. I'll be sure to buy a copy 
when it comes out! Thanks for all your hard work for this community, to 
you and your reviewers!


J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Shader lookup table method: does lookup texture have to be bound to a separate geometry?

[Jean-Sébastien Guay]

Hi Ethan,


Thanks Sergey, that clears it up for me.


Yes, Sergey has it right, that post was written from memory and 
obviously I got it backwards. I always cast the variable to int, or 
explicitly create a uniform of type SAMPLER_2D which avoids this issue 
altogether but is more lines of code.


Sorry for the confusion,

J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Shader lookup table method: does lookup texture have to be bound to a separate geometry?

[Jean-Sébastien Guay]

Hello Ethan,


Is a border being added to my texture somehow?  If so then this could explain 
why my shader is pulling non-uniform values from my uniform lookup table 
texture...


Set the wrap mode to CLAMP_TO_EDGE instead of CLAMP_TO_BORDER (which is 
the default, and the default border color is black).


It always seemed counterintuitive to me that OpenGL's default wrap mode 
is clamp to border, as this is a relic of times past and no one sets an 
appropriate border color anyways... Most of the time, you want either 
clamp to edge or repeat mode...


Hope this helps,

J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgdem] generate osgdem aligned with osgOcean

[Jean-Sébastien Guay]

Hello Rashad,


how to generate .ive files which can be aligned similar to islands.ive
in osgOcean.
osgOcean suites most of my needs. it can show islands.ive files but
works perfectly only with shipped resources cannot use custom resources
i build ive files using osdem. but the dem is not overlaying correctly
on ocean surface . i used cow.osg and it also work as expected . I also
played with few other ive and .osg files which works like charm
so the problem is with the .ive file generated with osgdem. how can I
generated .ive files for osgdem.

Is there any other way other than osgdem to genreate dems from SRTM or
tiff files


Are you sure your DEM is not simply below the ocean somewhere? Or 
perhaps your DEM is very far off in the distance? The oceanExample 
camera starts close to (0,0,0), so if you're loading your DEM into that 
to test, it may just be that your DEM is in global coordinates or 
somewhere far off... To test this you could load your DEM with cow.osg, 
if they end up very far apart that means your DEM is indeed somewhere 
far from (0,0,0).


As for the height, you can translate the ocean surface, have a look at 
OceanScene's API there is a way to set ocean height.


The DEM you are generating is presumably just geometry like any other, 
it should not behave differently than other models (though I can't be 
totally sure about that, it may be doing something weird, but I doubt 
it). cessna.osg is similarly bare-bones geometry and that works fine.


If you don't know what else to do, you can perhaps send (or place on 
some file-sharing site) a model containing a single level of a single 
tile of a DEM that demonstrates the problem, along with the command line 
that reproduces your problem with that data, and someone will probably 
try it out and see what they get.


Hope this helps,

J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Invitation to connect on LinkedIn

[Jean-Sébastien Guay]

Hi Robert,

I think this comes from the fact that LinkedIn can send invites to 
people in your address book, and users are using this with the osg-users 
list in their address book.


There's probably a way to block these, but user education might be good 
enough in the short term. I don't think anyone can "accept" an 
invitation on behalf of the whole osg-users mailing list anyways.


J-S


On 02/02/2012 3:44 AM, Robert Osfield wrote:

Hi All,

Getting invites from LinkedIn is NOT an acceptable use of the osg
mailing lists/forum.

If it's an automated thing then we need to squish it somehow.

Robert.



On 2 February 2012 03:33, Ariadie Chandra via LinkedIn
mailto:mem...@linkedin.com>> wrote:


  LinkedIn

Ariadie Chandra requested to add you as a connection on LinkedIn:

mingyue,

I'd like to add you to my professional network on LinkedIn.

- Ariadie

Accept



View invitation from Ariadie Chandra






*WHY MIGHT CONNECTING WITH ARIADIE CHANDRA BE A GOOD IDEA?*

*Ariadie Chandra's connections could be useful to you*

After accepting Ariadie Chandra's invitation, check Ariadie
Chandra's connections to see who else you may know and who you might
want an introduction to. Building these connections can create
opportunities in the future.

© 2012, LinkedIn Corporation


___
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



--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Request for input

[Jean-Sébastien Guay]

Hi Jason,


Any thoughts on these issues or other thoughts you could provide would
be very valuable.


I don't have that much to add. I commend you on your investigations, you 
really went to the crux of the problem and kept at it until you found 
the answer.


The mesh optimizers I've mentioned in the past (and I was tipped off to 
them by others, so it's not my own idea :-) ) really helped in the 
problem cases I was investigating too. I think it's really easy for 
modeling programs to produce bad data, and it's really hard in general 
to see that it's bad data until it's too late. Some bad aspects of the 
data can be dealt with by doing a post-optimization on the artists' 
data, but some bad aspects are very hard to automatically optimize and 
so require knowledge. Us 3D programmers have this task in addition to 
all our programming duties, we have to educate the data producers and 
others to be able to make good data! :-)


---(aside)---

As a side note, I think OSG suffers a bit from not having a "blessed" 
content creation pipeline. It allows implementers and users total 
flexibility, but also in so doing assumes a lot of knowledge that might 
not be there or take a long time to acquire, and indirectly promotes 
unoptimized bad data as described above. At a minimum, I would see 
benefit to adding


a) a set of "standard" export plugins for the most popular 3D modeling 
applications (3DSMax, Maya, Blender) which all give the same results and 
have the same options.
b) a "standard" optimizer that produces optimized models and textures. 
This optimizer would essentially be a beefed up osgconv that would do 
some optimizations automatically.


These would need to be maintained beside OSG itself so that people who 
download OSG will immediately know they can use them, instead of 
explicitly having to know they exist and searching for them (like the 
current Maya, Max and Blender plugins).


It's a large task, but I think it's totally worth it.

---(/aside)---

I think the remaining case that is not scaling well might indeed be down 
to some other part of OSG or the OpenGL driver that is being exercised 
more in that example than in others. Hard to say really, but if it's a 
plausible use case you can probably use the same methodology you used to 
investigate the previous issue, and you'll find the cause.


J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Is a render to texture master camera critical?

[Jean-Sébastien Guay]

Hello Martin,


So now my rtt camera is the master camera and my ortho camera for the quad is a 
nested camera (see the render_to_texture_scene_graph.png). It looks fine, but I 
am not sure whether it is a good idea.


That's always how I've done it too. I think it's fine.

For me, the motivation was that I wanted my app to work whether I was 
doing normal rendering or RTT of the main pass + post effects on a 
full-screen quad afterwards, so the common factor between the two needed 
to be that the master camera did the main scene rendering. Then I can 
switch between the two cases by simply changing the 
renderTargetImplementation of the main camera, attaching the output 
texture to the main camera's color buffer, and finally setting the node 
mask of the child ortho camera (that has the full-screen quad) to 
non-zero value.


Hope this helps,

J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Installation Problems.VS10 - unresolved external symbol

[Jean-Sébastien Guay]

Hello Kirill,


Project ->  Properties ->  General ->  Character Set ->  Use Multi-Byte 
Character Set


I think this is your mistake, I have never had to set this, and I 
believe it creates incompatible binaries. Meaning if the OSG libs were 
not compiled using multi-byte character set, and you try to link to them 
in a project that is, it will fail.


So if in your own project you change this back to the default, you 
should be able to use the pre-compiled binaries. Extra kudos for having 
tried all the other paths as well, though! I think they all failed for 
the same reason - even when you create your own project files using 
CMake from the OSG sources, it will not use multi-byte character set, so 
the binaries it compiled were incompatible with the project you created 
which did.


Hope this helps, let us know how it goes.

J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG website unresponsive

[Jean-Sébastien Guay]

Hi Chris,


   We could go on at length about why Git or Hg are superior to each other, and 
SVN, but
IMHG, Hg definitely has a lot better non-Linux support.


For Windows, there is the excellent Tortoisegit

http://code.google.com/p/tortoisegit/


I think that's the crux of the issue, what clients are available. 
Tortoisegit works well, I've used it in the recent past. Sure, you have 
to install msysgit to be able to use it, so you have some "unix on 
windows" tools installed on your system, which some people may dislike. 
But once the initial install is done, you can just forget you have 
msysgit installed at all, and use tortoisegit, and it's similar to 
tortoisesvn.


I've used this in the recent past and it's worked well for me, but I 
can't compare to mercurial as I haven't used it first hand. But I think 
it'll probably be similar, so if there's already some infrastructure 
support on github (and I really like the interface that site has) then 
it'll probably be a good choice.


That being said, I don't think there is a wrong choice...

J-S
--
__
Jean-Sebastien Guay  jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Reading osg files with images and xml files from archives on Android

[Jean-Sébastien Guay]

Hi Tom,


I now just have the issue that images referenced by .osg files are not loaded 
from the archive, anyone have any advice? The images are referenced relative to 
the .osg e.g. image\\diffuse.png


Have you seen Terry Welsh's thread on developing a virtual file system 
plugin so that a zip file can act as a directory? I think that would 
work for you, it would mean you don't have any manual things to do to 
make this work. I suggest you coordinate with him to test his solution 
and then suggest improvements. That way when he submits the finished 
product to be included in OSG it will fit your needs.


Other than that, I think you're probably left with implementing a 
ReadFileCallback to intercept the load requests for files referenced by 
your .osg files, and read them yourself from the zip archive.


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Problem with deferred rendering

[Jean-Sébastien Guay]

Hi Mical,


I recently have been trying to get a deferred rendering system to work using 
osg.


Lots of fun to come! :-)


   First of all in almost all the tutorials I've seen so far, the normal vector 
was multiplied by the normal matrix (gl_NormalMatrix), but when I did so in my 
geometry vertex shader, I had strange results (the normals where changing while 
I was moving in the scene) ... I later discovered that by leaving the gl_Normal 
untouched, I was getting the right result :|


The thing you have to remember when doing deferred rendering is what 
coordinate space you're in, and what coordinate space you want to be in. 
This forces you to really know what the built-in matrices in GLSL do, 
and what you should and should not use. Most tutorials are written with 
forward-rendering in mind, so they do things with that assumption. You 
can't.


(digression: this is one of the really nice things about OpenGL 3+, the 
built-ins are gone so it kind of forces you to know what matrices you 
need to pass and so on.)


Generally, what you want in deferred rendering is to store world-space 
values. That way, everything is in a common coordinate space, and once 
you do your light passes you will be able to use the same data for each 
light.


BUT, gl_NormalMatrix and gl_ModelViewProjectionMatrix bring normals and 
positions (respectively) into eye space, not world space. Same for 
ftransform(), you don't want to use that. That's why you saw the normals 
change when you moved the camera - they didn't actually change, it's 
just that they were in eye space, and eye space changes when you move 
the camera.


So using the vertex normal directly is almost correct. At least it's 
more correct than using the gl_NormalMatrix. It won't work correctly if 
your objects are rotated in the modeling transform (transforms between 
the camera and that object in the graph. You would have seen this for 
example if you animated your object to rotate all the time - lighting 
wouldn't change on it even though it's rotated differently with respect 
to the light source, because you're using object space normals, not 
transforming them to world space normals.


What you need in most cases is the model matrix, which in the G-buffer 
(main camera) pass you could get by using a cull callback on your 
G-buffer pass camera to set the camera's inverse view matrix in a 
uniform. Then you do:


mat4 modelMatrix = u_ViewMatrixInverse * gl_ModelViewMatrix;
mat3 modelMatrix3x3 = mat3(modelMatrix);

// world space
vWorldVertex = modelMatrix * gl_Vertex;
vWorldNormal = modelMatrix3x3 * gl_Normal;

Then you can pass those to your G-buffer fragment shaders as varyings.

Then, in the deferred pass(es) you'll need to do the rest of the job. Do 
most of your calculations in world space. Remember, once again, which 
space you're in: the gl_* matrices won't be of any use to you in the 
deferred passes, since you're rendering to a full-screen quad with an 
ortho projection probably so the matrices don't represent your main pass 
values at that point!


In particular, be careful to pass your light source's position/direction 
in world space in your own uniforms. OpenGL specifies that 
gl_LightSource[n].* are in eye space, but as I said the eye space of 
your deferred passes is not the same as the eye space of your G-buffer pass!


So it's really important for you to have a clear understanding of which 
space you're in at each step of your calculations in each of your 
shaders. It's a bit complicated but it's essential to pull off this 
technique.


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Color in ShapeDrawable

[Jean-Sébastien Guay]

Hi Anders,


Hence, it makes no sense storing a color in ShapeDrawable.


Well, it makes as much sense as having a color array for an 
osg::Geometry... :-)


I think it's not having a color in ShapeDrawable that's the problem, 
it's having no way of having no color. In other words, in osg::Geometry 
you have the ability to either set a color array or not. You should have 
the same ability in ShapeDrawable, i.e. set a color or not. Since 
osg::Color doesn't really have a "no color" value, you probably need an 
additional bool saying "use the color or not". When _useColor == false, 
then no glColor call would be made by ShapeDrawable itself, and the one 
from osg::Material would take effect.


Or you could just do what Robert always says, ignore ShapeDrawable even 
exists (except for simple debug geometry) and use osg::Geometry 
directly. Then you can do what you want.


I've wanted to rewrite ShapeDrawable to use osg::Geometry internally for 
a while, but I think Paul beat me to it in osgWorks... :-)


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Draw Instanced Help

[Jean-Sébastien Guay]

Hi Michael,


How would I set it up for instanced drawing?

My guess is that I would need to write a node-visitor that collects all
of the geometry ->  drawables and sets them up to use the instanced call
overload instead of the default. I have tried doing this, but my
implementation has gotten pretty complex, and I want to make sure there
isn't a more simple way I have overlooked.


You've got the right idea for the general way to apply instanced 
rendering for complex objects. But you can simplify usage by making your 
model simpler.


Draw instanced will work really well if your model consists of a single 
primitiveset. So ideally you'll have your modeler create the tree in a 
single geometry with a single primitiveset. They can make a texture 
atlas so that the same texture file applies to the whole geometry, and 
then merge all the geometry into a single one.


If this is not possible, you can try using the osgUtil::Optimizer to do 
this for you as a pre-process. Using the artist's model as input, you 
would apply the SHARE_DUPLICATE_STATE, FLATTEN_STATIC_TRANSFORMS, 
MERGE_GEODES, MERGE_GEOMETRY, VERTEX_PRETRANSFORM, VERTEX_POSTTRANSFORM, 
INDEX_MESH and possibly TEXTURE_ATLAS_BUILDER optimizers on it. I use 
this combination on all models by the way, in combination with a few 
custom visitors it does wonders to cull and draw times. What these will do:


TEXTURE_ATLAS_BUILDER: Will merge many small textures into a single 
larger one, adjusting texture coordinates, which can then be shared by 
all those nodes. An artist-created texture atlas is better though, I've 
seen cases where the texture atlas builder in OSG will create a really 
large texture and use less than half the space in it, and other such 
inefficiencies. A human will also be better equipped to judge of the 
qualitative criteria in making some textures smaller thus fitting more 
textures into a single atlas.


SHARE_DUPLICATE_STATE: Make sure identical state is shared (uses the 
same pointer to the same object) instead of having multiple state 
attributes with the same value throughout your model. You might have to 
write a small visitor to help this optimizer a bit, essentially 
normalizing all state that your modeling tool might set differently from 
what you expect, but which has no effect on the final output. For 
example you could force all geometry to single sided, etc. The idea is 
to make sure the next steps will be able to merge as much as possible.


FLATTEN_STATIC_TRANSFORMS: Remove any transforms that are marked as 
static data variance. You might have to make a small visitor that will 
change the data variance to static on any transforms that you don't 
really need. Modeling programs have a tendency to put lots of transforms 
all over the place (in Maya for example, there are no groups, everything 
is a transform, even graph leaves are a transform plus a geometry...). 
Again this will make the next steps work more efficiently, because 
things that are separated by a transform can't be merged together. You 
might want to write another simple visitor that would remove unnecessary 
Group nodes. Once again things that are separated by a Group can't be 
merged together.


MERGE_GEODES, MERGE_GEOMETRY: Merge as many scene graph leaves together 
as possible. Again this will make the next steps work more efficiently. 
Note that the MERGE_GEODES optimizer in OSG has a pretty serious "design 
flaw", it will only merge Geodes whose direct parent is a Group, and not 
any Group subclass. Sure, merging the children of an LOD node or Switch 
node is bad, but there are plenty of other subclass es of Group where it 
makes no difference. So I just subclassed the MergeGeodesVisitor so it 
checks the actual type of the parent, doesn't merge if it's certain 
types of Group subclasses (like LOD or Switch) but merges in all other 
cases.


VERTEX_PRETRANSFORM, VERTEX_POSTTRANSFORM, INDEX_MESH: This is a 
powerful trio of optimizers that will turn DrawArrays into DrawElements 
optimized for the GPU's cache, and merge all primitivesets under a 
Geometry together. After this, you might want to run the MERGE_GEODES 
and MERGE_GEOMETRY optimizers again, as they will be able to merge even 
more things together.


So anyways, I described why you would want to use the various optimizers 
for general models, but for your trees the goal is to end up with a 
single Geometry which has a single primitiveset. Then your job of doing 
instanced drawing of this tree becomes much easier. And again, if you 
can get your artist / modeler to make the model with this in mind, all 
the better. In general, if you can massage the data in order to make the 
code simpler, it's normally a win in the long run.


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
_

Re: [osg-users] transformation matrix explanation

[Jean-Sébastien Guay]

Hello Stefanos,


I am trying to find some documentation about these 4x4 but everything confuses 
me more and more. Please is there -anywhere- an explanation of these?


Indeed this is something you should know to be able to do 3D graphics. 
You can learn about transformation matrices in a good math book. Look 
for linear algebra, where you learn about matrices and vectors.


This site may help:

http://www.euclideanspace.com/maths/geometry/affine/matrix4x4/index.htm

But note that their representation of the matrix is transposed from 
yours, i.e. you have (0,0,0,1) as the last column, whereas they have it 
as the last line of the matrix. The whole column-major / row-major 
debate applies here, but in general just use the representation your 
software API (OpenGL and OSG in this case) use.



is it like I describe below?
   x  y   z ?
transform  0.00581384-0.997389   -0.0719816  0
translate   0.99705 0.0112907   -0.0759159  0
rotate   0.0765305  -0.0713279   0.994513   0
projection  -10.7682   9.27382   -316.446 1


No. The top-left 3x3 part of the matrix describes rotation and scale, 
and the last line describes translation. See the link above (but 
remember about the matrix transposition).



The thing is that I need to compute a distance using these two matrice. Is 
possible by using these numbers?


Distance from one object to the other? Simply subtract the translation 
of each matrix, which gives you the vector from one to the other. Then 
take the length of that. In OSG, you would do:


osg::Vec3 o1_to_o2 = o1Matrix.getTrans() - o2Matrix.getTrans();
double distance = o1_to_o2.length();

Hope this helps,

J-S
--
__
Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgViewer::GraphicsWindow::getWindowRectangle() results

[Jean-Sébastien Guay]

Hi Thomas,


I had developed some Qt code on Windows that worked great. When I compiled it 
on Linux, I noticed some oddities. The most interesting one is that:
 osgViewer::GraphicsWindow::getWindowRectangle()

returns an absolute window position in Windows (x != y != 0) whereas it seems 
to be relative in Linux (x = y = 0). Is that normal? Is that just the way it 
works with the different windowing? Should I be looking at the parent instead 
or something?


I've seen the same problem manifested differently: when someone (say 
Robert) develops an example and tests it in Linux, they will often call 
this function to create a default window:


  viewer.setUpViewInWindow(0,0,1024,768);

If I then run this example on Windows, the window's title bar will be 
outside the screen. So on Windows, it seems like the position (0,0) 
means the window's client area, whereas on Linux it means the window itself.


I guess someone should fix this inconsistency (just choose one behavior 
and stick to it on all OSes...)


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPPU] Blur artifacts in HDR effect

[Jean-Sébastien Guay]

Hello René,


also notice that the radius should be about 2.5 - 3 times sigma to make sure
the entire kernel is used instead of cutoff by the radius.


The default values in the osgPPU hdr example are sigma = 4.0 and radius 
= 7.0, however I have not seen a difference between radius = 7.0, 15.0 
and 200.0... So there I wonder if the values are getting to the shaders 
correctly.


What values would you suggest I use for good results?

Thanks,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPPU] Blur artifacts in HDR effect

[Jean-Sébastien Guay]

Hello René,


maybe multisampling can reduce the problem.


The screenshot was with 4x MSAA active (in the camera->attach(...) call 
of the HDR code, where we bind a texture to the main scene camera which 
is then passed to the first unit in the osgPPU pipeline).


Perhaps you're suggesting I enable MSAA for one of the other stages in 
the pipeline? How would I do that?



also you can add an additional gausian blur to the image before
resampling to reduce the artifacts.


Again using the same separable blur (x and y passes)? So I would add two 
other units before the UnitInResampleOut?


Thanks for your suggestions,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Getting Started - VS2010

[Jean-Sébastien Guay]

Hello Markus,


I'm trying to build an osg example but I can't get it linked.
Admittedly I am a C++ amateur, but I have followed some sort of guide
(http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/VisualStudio)
and was hoping to get it running with that.

It's the following code I try to get running: http://pastie.org/2894078
Here's the build log: http://pastie.org/2894074


Your compile and link flags seem good, except that you're compiling a 
debug build with /D NDEBUG. I would expect /D _DEBUG for a debug build. 
But that probably wouldn't cause the errors you're seeing.


Those errors would occur if you weren't linking to the right libraries, 
but I see them in your link command line, so I don't know what's wrong. 
Perhaps someone else on the list would care to venture a guess? 
Alternatively you could post a zip containing only your source and 
vcxproj/sln files, and we could try to compile it and see for ourselves.


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] multiple cull traversal for single object

[Jean-Sébastien Guay]

Hi Emmanuel,


=> The question I have is : to which extend could such a mechanism be used:
- would this still work as expected, if instead of changing the
Position, I were to change:

 1. A StateAttribute in a sub stateset ?
 2. An uniform value ?


No, not as simply as changing the position. The reason is that the cull 
visitor accumulates matrices by value, so each time you change the 
position and re-traverse you're adding a new matrix on the stack before 
each traversal. But Uniforms and state in general are accumulated by 
pointer (the last pointer that was in a StateSet when a drawable gets 
drawn is the one that is applied) so changing a uniform or other state 
attribute for the second traversal will change it for all "instances" of 
your object.


However you can do it another way: create different statesets with the 
different attributes you want, and before calling accept() each time, do 
cv->pushStateSet(ss1.get()); and after do cv->popStateSet(); .



- Are there some obvious issues I should be aware of when using this
approach ?


Not really, this is what the cull visitor does itself when it traverses 
a node (group, etc)...



And at the end I would consider directly
pushing the modelView matrix (to move to the proper tile location) on
the cull visitor, them traversing a shared tile template, then pushing
the next modelview matrix, etc... Any advise on this ? ;-)


This is what you're doing (indirectly) with your setPosition() between 
each accept(). So it's fine.


Hope this helps,

J-S
--
______
Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [vpb] Terrain Height as Texture

[Jean-Sébastien Guay]

Hi Jonathan,


It seams that there is no way to extract that information just form the vertex 
data (because the vertex shader only processes one vertex at a time).


Yes, sounds like what you need is more than what I thought you needed :-)

I don't think VPB supports that out of the box, but others may correct 
me, I have not used VPB that much. But you can surely load the height 
map from a texture. Then it comes down to knowing what texture 
coordinates in the height map correspond to each vertex / pixel, I guess 
you'd have to modify VPB to pass this as vertex attribute data or 
something like that.


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [vpb] Terrain Height as Texture

[Jean-Sébastien Guay]

Hi Jonathan,


I used osgdem to create a Terraindatabase from 2 image files (Heightmap and 
Colormap). Is there any way to access the height information in a texture? I 
need to do some calculations in the shader for which i need informations abount 
the surrounding terrain height, at guessed that it would be the easiest to look 
them up from a texture - but i only have the colormap in the *.ive files.


If you can relate scene units to real height in some way (say scene 
units are meters and Z=0 corresponds to "H" meters above sea level) then 
it's pretty trivial to do this without even having the height in a 
texture. Just transform vertex coordinates to world space in the vertex 
shader, output those in a varying, and in the fragment shader you'll 
have the world-space location of your pixel. The Z of this will be the 
height, relative to "H" above. You can pass "H" to the shaders in a 
uniform that you set at your scene root.


If you're in a weird projection then I wouldn't know, but this should 
work fine for flat-earth models I think.


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] [osgPPU] Drawing a mesh over an osgPPU output

[Jean-Sébastien Guay]

Hi all,

I hope there are some people using osgPPU who can answer my question. 
I'm having trouble doing something that I think should be simple, so if 
someone has any ideas I'd appreciate it.


What I need is to draw a mesh (which is a blending mesh, and whose 
vertices are in eye space) over the result of an osgPPU pipeline before 
outputting it to the framebuffer. My osgPPU unit is almost 100% like the 
HDR example's pipeline, without the text and background PPUs which I 
don't need.


What I tried is to add a transform (ABSOLUTE_RF) containing the mesh 
under the final unit in the pipeline. The result is that the mesh is not 
rendered.


I also tried adding the mesh (drawable only) under the final unit's 
geode. For this I had to create an overridden class so that the unit's 
init() method would not remove the drawable from the geode, and still it 
wasn't rendered in the result.


Is there already a tool in osgPPU that would allow me to do this easily? 
Or should I use a UnitCamera with my mesh under it?


Thanks in advance,

J-S
--
______
Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgviewerQt-Example

[Jean-Sébastien Guay]

Hello Patrick,


I can run it in release-mode w/o any problems, but when i switch to Debug, i 
get multiple Errors, when running the programm (Compiling is not an issue).
It stops working at the line
Code:
  QWidget* widget1 = addViewWidget( createCamera(0,0,100,100), 
osgDB::readNodeFile("cow.osgt") );

   .
Errors are in new.cpp, line 63 and crtexe.c, line 371. Unhandled Exceptions and 
access violations.


I assume you are using Windows / Visual Studio to build. You didn't 
mention it...


Sounds like the classic problem of mixing binaries built with different 
runtimes, or mixing versions of OSG. You should rigorously scrutinize 
your linker settings and path to make sure you aren't linking a debug 
built executable to a release built library, or using a release DLL with 
a debug executable, etc.


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgOcean] osgOcean time control

[Jean-Sébastien Guay]

Hello Bart,


Is there a way to setup osgOcean such that each time viewer.frame() is called, 
it only progresses a fixed time step?


See here:

http://code.google.com/p/osgocean/source/browse/trunk/include/osgOcean/FFTOceanTechnique#351

By default, osgOcean updates its ocean technique using real elapsed 
time, but you can use OceanAnimationCallback to give it whatever 
simulation time you want. You just override the operator() and in it, 
call update(..., mySimTime), like this:


class MyOceanAnimationCallback : public 
osgOcean::FFTOceanSurface::OceanAnimationCallback

{
public:
MyOceanAnimationCallback () {}

virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
double simulationTime = ...; // get simulation time
update(node, nv, simulationTime);
}
};

And set it on your ocean surface like this:

  oceanSurface->setOceanAnimationCallback(new MyOceanAnimationCallback);

I implemented this feature because we do networked simulations on 
multiple machines, and this allows us to synchronize the animation of 
the ocean on all machines given a synched simulation time value that is 
propagated on the network.


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] set material basic question

[Jean-Sébastien Guay]

Hi guys,


...I hate it when I do this...
What about PROTECTED states?  Could the nodes that aren't being
"correctly" affected by your material have a PROTECTED state, which
prevents your material from being applied?
See the thread "Override of an Override" for more information.


I just want to mention that the best way I know to debug these kinds of 
things is to dump the scene to a file ( osgDB::writeNodeFile(*root, 
"scene_dump.osg"); ), inspect it and try to view it in osgviewer. That 
way, you can see if your state was applied where you thought, if it's 
being overridden lower in the graph, etc. and you can even modify the 
file by hand, try it again in osgviewer and see if your problem is 
fixed, and then modify your code to do the same thing.


The thing with a scene graph is that you either have to know your graph 
inside-out and keep total control over it, or you have to make things 
very robust so that what you do always works no matter what the scene 
layout is. Visitors can help a lot with this.


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Migration of website and version control

[Jean-Sébastien Guay]

Hi Alberto,


Sorry about the nitpicking. Did you mean BitKeeper? :)


Err, yeah you're absolutely right. ;-)

J-S
--
__
Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Migration of website and version control

[Jean-Sébastien Guay]

Hi Brad,


It is a commercial product but they licence it free to open source projects 
(http://www.atlassian.com/software/views/open-source-license-request ).


I would advise against going with a commercial product that has a 
special license for open source projects. There has been a history of 
these companies either going away (the company goes bankrupt, where is 
your website then?) or just unilaterally removing support for open 
source projects when they disagree with something they did (Bazaar for 
example, which prompted the development of git).


I think an open source project should rely on open source projects for 
its infrastructure and community management. It just makes sense.


I've had some experience managing a few small wikis using MediaWiki, 
it's powerful and easy to use. The only thing that might be missing is 
some plugin to integrate it with git, but I'm sure something like that 
exists already, we just have to search a bit.


J-S
--
__
Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] EXTERNAL: Re: Draw Elements Instanced Shader Help

[Jean-Sébastien Guay]

Hi Paul and Alexander,


This has been discussed extensively recently, but I don't recall the
resolution. If you can't find any information by searching the archives,
then you might try posting a new thread (as it has nothing to do with
draw instanced).

It might already be fixed on trunk, so if you aren't on trunk, perhaps
you should try that.


It is. See:

http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osg/Program.cpp?rev=12816

The change was committed shortly after the 3.0.1 release, so the next 
release should contain it. The commit message was:


"Added removal of [..] from names returned from glGetActiveUniform 
results to avoid issues with name lookups when the driver add the [..] 
for uniform arrays."


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [SOLVED] Deriving my own Effect/Technique class - heap damage error

[Jean-Sébastien Guay]

Hi Matthias,


Some weeks ago, I posted my original problem, when deriving my own 
Effect/Technique class. I'm happy to add that both the heap damage error and 
the memory leak are solved, now. (In fact, there were some similar errors and I 
couldn't ignore or workaround them any more.)
It was not the mixing of debug and release binaries, but some incompatible 
compiler settings: My project compiled with /MT and /MTd respectively, while 
OSG links the C Runtime dynamically (/MD and /MDd respectively). Here are some 
forum threads which helped me to get the clue and describe in more detail which 
flags to regard:


Ah yes, the "mixing debug and release" argument is often an 
oversimplification of the actual problem, which is mixing incompatible 
runtimes. I make that terminology mistake very often... sorry...


Good to know you got to the bottom of it.

J-S
--
______
Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] VBO Bug ?

[Jean-Sébastien Guay]

Hi Wojtek,


Hehe, do you read my mind ? You posted the answer before my question I
arrived on the list.
I will send them broken model then. If they have osg installed, they
could easily see the OpenGL calls with glDebuger.


I suggest you send them a zip with osgviewer and the required DLLs too, 
just to simplify their life. I doubt they have OSG installed, and 
requiring them to go get the binaries will just be a barrier to them 
examining this bug.


J-S
--
__
Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] VBO Bug ?

[Jean-Sébastien Guay]

Hi Wojtek,


Sebastian: Just out of curiosity where do you send or post OpenGL bugs ?
Thru Registered developer's site or NVidia forums ? I have mixed results
with registered devs site. Maybe other paths are a faster ?


Please see my message, generally there's no need to make a pure OpenGL 
test case, and I gave you the e-mail address to send to directly :-)


J-S
--
__
Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] VBO Bug ?

[Jean-Sébastien Guay]

Hi guys,


So maybe we should try to reproduce this with pure OpenGL and send a
sample to NVidia (they have been very responsive in the past if you send
an example)


And actually in my experience, even if you send an OSG-based example 
(binaries only) they can reproduce it and look at the OpenGL calls and 
find the problem that way. You don't even need to make a pure OpenGL 
example. I agree, they've been responsive, which reminds me I still 
haven't sent a repro example for an Optimus bug I found...


Dev Support 

Hope this helps,

J-S
--
__
Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Viewer thread safety question

[Jean-Sébastien Guay]

Hi Joshua,

I'm wondering, have you tried just adding / removing nodes in your graph 
before calling frame() on your viewer?


The Draw traversal, which may still be running when the previous frame() 
returns, should theoretically not care about changes in the graph. 
That's because the cull traversal gathers statesets and drawables into 
its own lost, stored in ref_ptrs, and then the draw phase dispatches the 
draw calls for those based on the list gathered during cull.


But when frame() returns, cull is finished, and update for the next 
frame hasn't started yet, so it should be safe to modify the graph at 
that point. Any nodes you remove from the graph don't matter since draw 
has stored all the drawables and statesets (that it needs) in ref_ptrs. 
And no other traversals are running (draw is not technically a 
traversal, since it has its own list and doesn't traverse the graph), so 
no iterators will be invalidated by adding or removing children in your 
graph.


The DYNAMIC data variance only applies to drawables and statesets, for 
that same reason. It's those things that the draw traversal may be using 
at the same time as another thread, so it's those things that need to be 
dispatched before frame() returns.


The things that need special care are adding / removing views in a 
CompositeViewer, or replacing the graphics context on a camera, or 
things like that. For those, you'll generally have to stopThreading() 
before, then startThreading() after the operation, to make sure no draw 
threads are running when you do them.


But changing the graph can safely be done between calls to frame(), that 
shouldn't be a problem.


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] BUG report: Collada orthographic support

[Jean-Sébastien Guay]

oth
the camera information and the models).
I cannot just hard code the camera once and for all.

As I asked before,
is still someone in the reading list familiar with this part of the code ?
Any idea of how trivial or non trivial it is to fix this issue ?

I am not familiar with the specifics of the camera matrices handling
in OSG, but I would believe the issue to be "not very had" to resolve.

Best regards,
rodrigob.


On Sat, Oct 8, 2011 at 10:24 PM, Gordon Tomlinson
  wrote:

To me Its not a bug , its an unsupported feature :) so you cannot really 
reports it a as bug

There are many features of what Collada can support that are not supported in 
OSG or other apps. ( this is also the same of other model formats)
Not every feature of of every formats is needed in OSG in general or really 
makes sense

I for one would Not want to use camera data in my application when loading a 
DAE model (or any format),  my application controls the camera not a model, I 
just want to load the models, what if I load 30 Dae models and they all have 
different cameras , which one should I use :(m but that’s me and my apps

Too me your request is more an Application specific thing and you could extend 
your application to create that Ortho camera for you, it would be a good way to 
learn more about OSG




__
Gordon Tomlinson

gor...@gordontomlinson.com
www.photographybyGordon.com
www.vis-sim.com
www.gordontomlinson.com
IM: gordon3db...@3dscenegraph.com
__

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Rodrigo 
Benenson
Sent: Saturday, October 08, 2011 9:26 AM
To: OpenSceneGraph Users
Subject: [osg-users] BUG report: Collada orthographic support

Thanks Jean-Sébastien for the quick answer.
If the mailing list is the bug report channel, then here I go:

I am currently working on an application that uses openscenegraph to
render collada animations.
When running my code on the collada files of my interest I get the
following warning:

Orthographic in  'Camera-camera' not supported

not support orthographic projection will clearly "mess up" the rendering output.
Looking into the code I found
http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgPlugins/dae/daeRSceneObjects.cpp?rev=12791#L617

616 // TODO The current osg::CameraView does not support an
orthographic view
617 OSG_WARN<<  "Orthographic in  '"<<
dcamera->getId()<<  "' not supported"<<  std::endl;

Looking at the code it seems that the information from the collada
file is properly extracted, but the actual CameraView setup is not
"supported".
However looking at the examples there is for instance
http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/examples/osghud/osghud.cpp#L47

which shows that orthographic projection is supported in the current
version of OpenSceneGraph.

In my eyes then, implementing the support of orthographic projection
when loading collada file seems like a missing feature that should be
documented in a bug report.

I am not familiar enough with OpenSceneGraph to just "come a patch"
but the issues seems simple enough to fix. Is anyone familiar with
this part of the code ?

Regards,
rodrigob.


On Sat, Oct 8, 2011 at 2:11 PM, Jean-Sébastien Guay
  wrote:

Hi Rodrigo,


I just spent 20 minutes looking around in
http://www.openscenegraph.org I could not find how users are supposed
to report bugs (I did find how to send patches, but not how to report
bugs).

Could someone point me out how to do this ?


Actually you just found it :-)

The OSG project uses the mailing list for pretty much everything. That's
just the way it has always been. There are plans to change this process in
the future, which leads to the next point:


ps: I am surprised that emails are used for patches, instead of the
facilities of https://github.com/openscenegraph/osg


The official OSG repo is hosted on openscenegraph.org and uses SVN. It is
not using git yet, though there are plans in the coming year to move to git.
The github repo is a mirror of the openscenegraph SVN repo maintained by
members of this mailing list. So patches you would submit on github would
just be lost.

Hope this helps,

J-S
--
__
Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


__

Re: [osg-users] Bug report procedure ?

[Jean-Sébastien Guay]

Hi Rodrigo,


I just spent 20 minutes looking around in
http://www.openscenegraph.org I could not find how users are supposed
to report bugs (I did find how to send patches, but not how to report
bugs).

Could someone point me out how to do this ?


Actually you just found it :-)

The OSG project uses the mailing list for pretty much everything. That's 
just the way it has always been. There are plans to change this process 
in the future, which leads to the next point:



ps: I am surprised that emails are used for patches, instead of the
facilities of https://github.com/openscenegraph/osg


The official OSG repo is hosted on openscenegraph.org and uses SVN. It 
is not using git yet, though there are plans in the coming year to move 
to git. The github repo is a mirror of the openscenegraph SVN repo 
maintained by members of this mailing list. So patches you would submit 
on github would just be lost.


Hope this helps,

J-S
--
__
Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Changing vertex color without calling setColorArray

[Jean-Sébastien Guay]

Hello Dan,


   The main problem with calling setColorArray to update the vertex colors is 
that it visibly slows the framerate. Is there any way around completely 
resetting the color array on the geometry every frame (update)?


Calling setColorArray() calls dirtyDisplayList(), which is what is 
actually needed in order for the display lists to be recompiled and 
ready to use with your changes.


If you are updating the color array (or indeed any array in the 
Geometry) often, then you should just disable display lists by calling 
setUseDisplayLists(false). Also you can experiment with 
setUseVertexBufferObjects(true), for some uses vertex buffer objects are 
faster than plain vertex buffers but in some cases they are slower.


Display lists are for static geometry. If your geometry is changed 
often, the overhead of compiling the display list will severely affect 
frame rate as you have seen.


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] How to setup and confirm a proper forward-compatipble GL3 context

[Jean-Sébastien Guay]

Hi Peter,


I activated the uniforms, but still the uniforms don't get printed
through my update callback.
When I activate these uniforms, does this mean at all that they should
be get in any StateSet of any Node ? I think they should, as otherwise I
couldn't use them, right ?


No, they get pushed into the state by the SceneView and other internal 
classes, so it's very possible that you'll never see them in any 
StateSet. As I said before:


>> Search in the OSG sources for getUseModelViewAndProjectionUniforms()
>> and getUseVertexAttributeAliasing() and you'll see where they are used
>> to create and update the uniforms / variables.

Hope this helps,

J-S
--
______
Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG Multi-threading questions

[Jean-Sébastien Guay]

Hi George,


Can I also assume that after viewer::frame() returns, it is guaranteed that no 
OSG threads related to rendering or scene traversal are running?


Rendering : no you can't assume this.
Scene traversal : yes you can assume this.

The explanation:

In some multithreading modes (see 
osgViewer::ViewerBase::setThreadingModel) frame() will return when the 
DYNAMIC drawables / state have been dispatched. So if you're modifying 
drawables / state in the update phase (before calling frame() or in an 
update callback) you need to mark those as DYNAMIC (see 
osg::Object::setDataVariance). osgText::Text objects are perfect 
examples of this - if you modify one such object by calling setText() on 
it, you need to mark it as DYNAMIC.


However, at that point (between calls to frame()), the graph structure 
is not needed anymore by the draw threads, so you're free to modify the 
structure as you want. Just make sure, if you modify the graph structure 
in the update traversal, that you only do it for your children, 
otherwise you'll be invalidating iterators and will get crashes.



Can I ask what is the use of viewer::start/stopThreading() then?


Things that affect the draw traversals sometimes need draw threads to be 
stopped completely. Things like adding views to a CompositeViewer, or 
changing the graphics context on a camera, or things like that. It's 
pretty rare you need to do this. It's also pretty costly, because 
stopThreading() will only return once the draw threads have been stopped 
and deleted, and startThreading() only returns once new draw threads 
have been created and started.


Hope this helps,

J-S
--
______
Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] CMake INSTALL target and vc10

[Jean-Sébastien Guay]

Hi Mattias,

Thanks for your hints, I certainly don't want to bother you with testing 
anything, just having a look and giving me some hints is useful. I'll 
check out what you said tomorrow.


Thanks,

J-S


On 05/10/2011 2:50 PM, Mattias Helsing wrote:

Hi J-S,

I'm not at windows computer so can't get into testing, but I think you
might find some magic in the HANDLE_MSVC_DLL macro. I'm guessing that
the young osgPPU build system was inspired by the osg one and in the
last months I think there were some substantial changes to
OsgMacroUtils.cmake including the HANDLE_MSVC_DLL macro.

Hmm. Looking at the file you attached. Doesn't osg's
ModuleInstall.cmake call HANDLE_MSVC_DLL only if the
MSVC_VERSIONED_DLL (or similar) is defined? I might be mistaken. Will
check tomorrow.

Mattias

On Tue, Oct 4, 2011 at 7:23 PM, Jean-Sébastien Guay
  wrote:

Hi Mattias,


The osgPPU.dll it's trying to copy is actually in

C:\Dev\OSG_Nodekits\osgPPU\build_vc10sp1_osg283\lib\Release


Actually I was wrong, that was an old one. The one it's building now is
correctly in

C:\Dev\OSG_Nodekits\osgPPU\build_vc10sp1_osg283\bin

So it seems that the problem is the install, which tries to find it in

C:/Dev/OSG_Nodekits/osgPPU/build_vc10sp1_osg283/bin/../../bin

(it could just remove the ../../bin and find it there)

How can I control where the install target tries to find stuff? Here is the
ModuleInstall.cmake file that comes with osgPPU source.

Thanks in advance,

J-S
--
______
Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.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




--
______
Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] retrieve texture id

[Jean-Sébastien Guay]

Hello Conan,


I create my gc manually then create viewer/window etc... so my code looks like 
this:

unsigned int contextID = gc.get()->getState()->getContextID()
unsigned int textureID = texture[0]->getTextureObject(contextID)->id();

Upon executing the "textureID = " I get a seg fault, and upon further checking,  
texture[0]->getTextureObject(contextID) = 0.


(you don't need gc.get() above, ref_ptr has an overloaded operator-> 
that takes care of that for you so you can just do gc->... )


As with any pointer access in C++ programming, you have to be sure that 
when you do something, you're not dereferencing a null pointer.


What you're doing is perfectly fine, as long as you do it after the 
first frame has rendered. The getTextureObject(...) call will return 
NULL before that, because OSG uses lazy initialization to only allocate 
objects once they're needed. OpenGL objects and the OSG objects that 
hold them are examples of this.


So the safest way is to just let OSG render one frame, and then you can 
get your texture object (for example, check if the result of 
getTextureObject() is NULL, if not then get your texture ID, and then do 
your thing).


If you really want to, you can force OSG to allocate all objects in your 
scene at startup by doing this:


viewer->realize();
viewer->stopThreading();

gc->makeCurrent();

osgUtil::GLObjectsVisitor glov;
glov.setState(gc->getState());
viewer->getCamera()->accept(glov);

gc->releaseContext();

viewer->startThreading();

Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] retrieve texture id

[Jean-Sébastien Guay]

Hi Conan,

(I have the impression your name is a pseudonym, I wonder why... ;-)


[dumbquestion]

I am integrating some cuda into my osg app and one call requires the texture 
name/id.  How do I get that from my texture object?  I look through the source 
code and only found and id method in TextureObject, but my attempts to 
retrieive this bit of data eludes me.

[/dumbquestion]


Not a dumb question at all, part of learning how to use OSG is learning 
how the things fit together and what to do to get to the information you 
need...


From an osg::Texture* (Texture2D, etc.) you have access to the 
interface of osg::Texture (which Texture2D et al are subclasses of). But 
first, to get to your OpenGL texture ID for a given Texture2D, you need 
the context ID in which you want to get that information, which you can 
get for example from the GraphicsContext like so:


unsigned int contextID = gc->getState()->getContextID()

Then you can do:

GLuint textureID = texture->getTextureObject(contextID)->id();

to get the ID of the texture object in that context.

Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] CMake INSTALL target and vc10

[Jean-Sébastien Guay]

Hi Mattias,


The osgPPU.dll it's trying to copy is actually in

C:\Dev\OSG_Nodekits\osgPPU\build_vc10sp1_osg283\lib\Release


Actually I was wrong, that was an old one. The one it's building now is 
correctly in


C:\Dev\OSG_Nodekits\osgPPU\build_vc10sp1_osg283\bin

So it seems that the problem is the install, which tries to find it in

C:/Dev/OSG_Nodekits/osgPPU/build_vc10sp1_osg283/bin/../../bin

(it could just remove the ../../bin and find it there)

How can I control where the install target tries to find stuff? Here is 
the ModuleInstall.cmake file that comes with osgPPU source.


Thanks in advance,

J-S
--
__
Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
# INSTALL and SOURCE_GROUP commands for osgPPU

# Required Vars:
# ${LIB_NAME}
# ${LIB_PUBLIC_HEADERS}

# --
# Setup destination directories
# --
SET(INSTALL_INCDIR include)
SET(INSTALL_BINDIR bin)
SET(INSTALL_SRCDIR src)
IF(WIN32)
SET(INSTALL_LIBDIR bin)
SET(INSTALL_ARCHIVEDIR lib)
ELSE(WIN32)
SET(INSTALL_LIBDIR lib)
SET(INSTALL_ARCHIVEDIR lib)
ENDIF(WIN32)

IF(MSVC)
HANDLE_MSVC_DLL()
ENDIF(MSVC)

INSTALL(
TARGETS ${LIB_NAME}
RUNTIME DESTINATION ${INSTALL_BINDIR}
LIBRARY DESTINATION ${INSTALL_LIBDIR}
ARCHIVE DESTINATION ${INSTALL_ARCHIVEDIR}
)


# --
# Setup header file group for Visual Studio
# --
SET(HEADERS_GROUP "Header Files")
SOURCE_GROUP(
${HEADERS_GROUP}
FILES ${LIB_PUBLIC_HEADERS}
)

# --
# Setup source file group for Visual Studio
# --
SET(SRC_GROUP "Source Files")
SOURCE_GROUP(
${SRC_GROUP}
FILES ${LIB_SRC_FILES}
)


# --
# Install routines for differnet components
# FIXME: Do not run for OS X framework
# --
INSTALL(
FILES${LIB_PUBLIC_HEADERS}
DESTINATION  ${INSTALL_INCDIR}/${LIB_NAME}
COMPONENT${PACKAGE_HEADERS} 
)

INSTALL(
FILES${LIB_SRC_FILES}
DESTINATION  ${INSTALL_SRCDIR}/${LIB_NAME}
COMPONENT${PACKAGE_SRC}
)

#---
# Include the build system parts to the source package
#---
INSTALL (
FILES
${PROJECT_SOURCE_DIR}/CMakeLists.txt
${PROJECT_SOURCE_DIR}/ChangeLog
${PROJECT_SOURCE_DIR}/CONTRIBUTORS.txt
${PROJECT_SOURCE_DIR}/LICENSE.txt
DESTINATION ./
COMPONENT  ${PACKAGE_SRC}
)

INSTALL (
FILES
${PROJECT_SOURCE_DIR}/src/CMakeLists.txt
DESTINATION src
COMPONENT  ${PACKAGE_SRC}
)

INSTALL (
FILES
${PROJECT_SOURCE_DIR}/src/osgPlugins/CMakeLists.txt
DESTINATION src/osgPlugins
COMPONENT  ${PACKAGE_SRC}
)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] CMake INSTALL target and vc10

[Jean-Sébastien Guay]

Hi Mattias,


I think the easy solution is to set:
CMAKE_ARCHIVE_OUTPUT_DIRECTORY, CMAKE_RUNTIME_OUTPUT_DIRECTORY and
CMAKE_LIBRARY_OUTPUT_DIRECTORY properly.


Where do I have to set these?

I tried inserting the code you gave either in the ModuleInstall.cmake 
module, or in the top-level CMakeLists.txt (after the PROJECT(...) line) 
and it didn't seem to change anything. I think the problem is that even 
though I'm setting the CMAKE_*_OUTPUT_DIRECTORY variables, the DLLs are 
still falling in a "Release" or "Debug" directory under lib... But I 
don't know why. I even tried removing my build directory (including the 
CMakeCache.txt) and rebuilding, but that didn't help. Can you help me 
figure out what is going wrong?


Here is what I added:

set(OUTPUT_BINDIR ${PROJECT_BINARY_DIR}/bin)
set(OUTPUT_LIBDIR ${PROJECT_BINARY_DIR}/lib)
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${OUTPUT_LIBDIR})
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${OUTPUT_BINDIR})
if(WIN32)
  set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${OUTPUT_BINDIR})
else()
  set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${OUTPUT_LIBDIR})
endif()

# For each configuration (Debug, Release, MinSizeRel... and/or anything 
the user chooses)

foreach(CONF ${CMAKE_CONFIGURATION_TYPES})
# Go uppercase (DEBUG, RELEASE...)
STRING(TOUPPER "${CONF}" CONF)
set("CMAKE_ARCHIVE_OUTPUT_DIRECTORY_${CONF}" "${OUTPUT_LIBDIR}")
set("CMAKE_RUNTIME_OUTPUT_DIRECTORY_${CONF}" "${OUTPUT_BINDIR}")
if(WIN32)
set("CMAKE_LIBRARY_OUTPUT_DIRECTORY_${CONF}" "${OUTPUT_BINDIR}")
else()
set("CMAKE_LIBRARY_OUTPUT_DIRECTORY_${CONF}" "${OUTPUT_LIBDIR}")
endif()
endforeach()

MESSAGE("PROJECT_BINARY_DIR=${PROJECT_BINARY_DIR}")
MESSAGE("OUTPUT_LIBDIR=${OUTPUT_LIBDIR}")
MESSAGE("CMAKE_ARCHIVE_OUTPUT_DIRECTORY=${CMAKE_ARCHIVE_OUTPUT_DIRECTORY} ...")
MESSAGE("CMAKE_RUNTIME_OUTPUT_DIRECTORY=${CMAKE_RUNTIME_OUTPUT_DIRECTORY} ...")
MESSAGE("CMAKE_LIBRARY_OUTPUT_DIRECTORY=${CMAKE_LIBRARY_OUTPUT_DIRECTORY} ...")

And I don't see anywhere else where the CMAKE_*_OUTPUT_DIRECTORY 
variables are modified. The output I get from my MESSAGE lines is:


1>  PROJECT_BINARY_DIR=C:/Dev/OSG_Nodekits/osgPPU/build_vc10sp1_osg283
1>  OUTPUT_LIBDIR=C:/Dev/OSG_Nodekits/osgPPU/build_vc10sp1_osg283/lib
1> 
CMAKE_ARCHIVE_OUTPUT_DIRECTORY=C:/Dev/OSG_Nodekits/osgPPU/build_vc10sp1_osg283/lib 
...
1> 
CMAKE_RUNTIME_OUTPUT_DIRECTORY=C:/Dev/OSG_Nodekits/osgPPU/build_vc10sp1_osg283/bin 
...
1> 
CMAKE_LIBRARY_OUTPUT_DIRECTORY=C:/Dev/OSG_Nodekits/osgPPU/build_vc10sp1_osg283/bin 
...


and the error I get when building the INSTALL target is:

3>  CMake Error at src/osgPPU/cmake_install.cmake:50 (FILE):
3>file INSTALL cannot find
3> 
"C:/Dev/OSG_Nodekits/osgPPU/build_vc10sp1_osg283/bin/../../bin/osgPPU.dll".

3>  Call Stack (most recent call first):
3>src/cmake_install.cmake:33 (INCLUDE)
3>cmake_install.cmake:32 (INCLUDE)

The osgPPU.dll it's trying to copy is actually in

C:\Dev\OSG_Nodekits\osgPPU\build_vc10sp1_osg283\lib\Release

The top-level CMakeLists.txt is attached. I am using CMake 2.8.4.

Thanks in advance,

J-S
--
__
Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
CMAKE_MINIMUM_REQUIRED(VERSION 2.4.5 FATAL_ERROR)

# Setup compatibility modes
IF(COMMAND cmake_policy)
if(POLICY CMP0011)
cmake_policy(SET CMP0011 OLD) # or NEW
endif(POLICY CMP0011)

cmake_policy(SET CMP0003 NEW)
ENDIF(COMMAND cmake_policy)



# Set default values

PROJECT(osgPPU)
SET(CMAKE_MODULE_PATH 
"${osgPPU_SOURCE_DIR}/CMakeModules;${CMAKE_SOURCE_DIR}/CMakeModules;${CMAKE_MODULE_PATH}")
SET(SOURCE_DIR ${osgPPU_SOURCE_DIR})
SET(OSG_DIR "${CMAKE_INSTALL_PREFIX}" CACHE STRING "Path where to find the osg 
installation")
SET(CUDA_DIR "${CMAKE_INSTALL_PREFIX}/cuda" CACHE STRING "Path where to find 
the cuda installation")

set(OUTPUT_BINDIR ${PROJECT_BINARY_DIR}/bin)
set(OUTPUT_LIBDIR ${PROJECT_BINARY_DIR}/lib)
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${OUTPUT_LIBDIR})
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${OUTPUT_BINDIR})
if(WIN32)
  set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${OUTPUT_BINDIR})
else()
  set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${OUTPUT_LIBDIR})
endif()

# For each configuration (Debug, Release, MinSizeRel... and/or anything the 
user chooses)
foreach(CONF ${CMAKE_CONFIGURATION_TYPES})
# Go uppercase (DEBUG, RELEASE...)
STRING(TOUPPER "${CONF}" CONF)
set("CMAKE_ARCHI

[osg-users] CMake INSTALL target and vc10

[Jean-Sébastien Guay]

Hi all,

I vaguely remember there being a discussion about this when vc10 came 
out, but I don't remember the conclusion or what fixed it for OSG, so...


I'm trying to compile osgPPU for vc10, and I'm getting this error when 
building the INSTALL target:


2>  -- Installing: 
C:/Dev/OSG_Nodekits/osgPPU/install_vc10sp1_osg283/lib/osgPPUd.lib

2>  CMake Error at src/osgPPU/cmake_install.cmake:47 (FILE):
2>file INSTALL cannot find
2> 
"C:/Dev/OSG_Nodekits/osgPPU/build_vc10sp1_osg283/lib/Debug/../../bin/osgPPUd.dll".


The problem is that osgPPUd.dll is not in
  lib/Debug/../../bin/osgPPUd.dll
but in
  lib/Debug/../../bin/Debug/osgPPUd.dll

As I said, I'm pretty sure I saw people reporting this for OSG on vc10 
when it came out, but I wasn't using vc10 back then so I don't remember 
what the solution was... Can anyone refresh my memory please? :-)


Thanks in advance,

J-S
--
______
Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgText::Text heap corruption when using setText()

[Jean-Sébastien Guay]

Hi Joshua,


So, all user input is considered before the frame() function is called 
including the call to change text.  I guess this is what is confusing me; if I 
call setText(std::string) before I call frame() shouldn't the osgText::Text 
object have all of its data primed and ready before the drawing update occurs?


Actually, it's the other way around. If you're running your viewer 
multithreaded, the draw for frame n-1 might still be running when the 
update for frame n starts. So you might be calling setText() right 
before the frame() for frame n, but the draw for frame n-1 is still 
running and so still trying to access the text object.


This is what setting the data variance to DYNAMIC prevents. Essentially, 
it holds back starting the next update (actually returning from the 
frame() function, indirectly) until all drawables flagged DYNAMIC have 
been dispatched, which means that once you get to updating your text 
object in frame n, frame n-1 will already have drawn your text, so it 
won't be trying to access the same object you're updating.


That's one problem, which you can fix by updating in your frame loop or 
having a mutex there, or by using an update callback as I described in 
my previous message. But the fact of trying to update your text from 
another thread (without any control over when that update happens) can't 
ever work, and using a mutex between that and the frame loop is IMHO a 
bad idea, which is why I suggesting using an intermediate data hold 
between your thread and an update callback that would do the actual 
updating. But that's up to you as to how you want to design your code... 
Once I've given you the technical reasons for why you were getting a 
crash, it's up to you to decide how to do things to avoid it.


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgText::Text heap corruption when using setText()

[Jean-Sébastien Guay]

Hi Joshua,


I hacked a fix into the code and found that it works quite well if there is a 
mutex locker blocking anything that might change the text in osgText.cpp.


This has been discussed a lot in the past. You can't just run threads 
that will go call stuff in OSG at any time. You need to modify most 
things during the update traversal (which is essentially what your mutex 
ensures). This is indeed a hack.


What I would suggest instead, to prevent threads waiting for one another 
and to prevent you setting the text on your osgText object multiple 
times between two frames (which can be expensive in my experience, for 
something the user will never see) is to have a simple buffering scheme.


1. Your thread can put the text values you want to display in some 
holding area (which you would lock to ensure writing to it is threadsafe).
2. An update callback on your osgText object would go get the latest 
value in your holding area, compare it with the last value that was set, 
and only if it's different will set it on the osgText object.


Your osgText object still has to have DYNAMIC data variance, so that the 
viewer knows to hold back the next frame until that object's update is 
done. But the advantage of the above suggestion is really that two 
threads won't wait for each other, they will really hold the mutex (for 
your holding area) a minimum of time. Plus it's less intrusive on your 
main loop - you can encapsulate all that in a simple class, and if you 
need to add more text objects later, you don't need to add other mutexes 
or modify your main loop in any way.


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org