Re: [osg-users] Aircrft HUD, how to make viewports to contain different HUD indicators ?

2013-06-03 Thread Jeremy Moles

On 06/03/2013 01:07 AM, Mahdi Samadzad wrote:


Dear All,

I need to create an aircraft HUD with its many indicators for 
airspeed, altitude, heading, Horizontal Situation Display and Vertical 
Deviation Indicator. It should look like this: 
http://www.loop-net.info/hud/fl.html


I think I should be able to draw all lines using osg::Geometry and 
show all texts using osg::Text. But where I cannot figure out the way 
to go is in creating different viewports that contain scrolling texts 
and the rotating VDI.


Would you please help ? by the way do you know any tutorial on 
creating aircraft HUDs ?


Many thanks in advance,
Mahdi

Depending on your performance needs, you might be able to get away with 
using a 2D vector drawing library like Cairo and have that render into a 
texture (or group of textures) to draw your HUD. I've done exactly this 
many, many times for various clients using OpenSceneGraph (mostly little 
widgets for software in the medical industry) but it's fast enough on 
modern hardware, even with Intel GPUs.


You could also look into using the NV_path_rendering (and/or osgNVPR), 
if your software will only ever run on NVidia cards. It's the kind of 
thing the extension was designed for, it just hasn't caught on like it 
could since ATI doesn't have anything similar...


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


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


Re: [osg-users] Culling w/ RTT

2013-05-28 Thread Jeremy Moles

On 05/28/2013 01:20 PM, Farshid Lashkari wrote:

Hi Jeremy,

This sound very similar to an issue I've encountered before. Does your 
RTT Camera object use a RELATIVE or ABSOLUTE reference frame? Also, 
are you applying any ComputeBoundingSphereCallbacks to you scene or 
override the computeBound method of any nodes?



ABSOLUTE.

And no, I'm not applying any BoundingSphere callbacks...

Cheers,
Farshid



On Mon, May 27, 2013 at 11:07 AM, Jeremy Moles cubic...@gmail.com 
mailto:cubic...@gmail.com wrote:


Hello everyone! I'm running into a problem in my application where
I'm trying to switch between two different subgraphs as the result
of some event (key press or similar). The first of these two
objects is a standard subgraph with nothing too sophisticated
going on. The second of these is a RTT stack of Camera objects.

The problem manifests in that if I switch FROM the standard graph
(just a random grouping of models) to the RTT Camera stack, the
bounds of the previous node are used for the RTT Camera. This
means that while the same scene rendered within my RTT stack is
fine as long as you don't adjust the view matrix, as soon as you
move the scene around it begins to get culled. I can remedy this
problem by disabling culling on the main viewer camera when my RTT
stack is in effect, but I feel like I'm doing something wrong...
the reason I think this is because I can add the RTT stack to my
scene as the FIRST scene (and never toggle it to anything else)
and the culling occurs correctly. The problem only manifests when
I switch from the RTT stack to a standard node AND THE BACK to the
RTT scene.

Has anyone tried anything like this in the past? Does anyone have
any hints? :)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto: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


[osg-users] Culling w/ RTT

2013-05-27 Thread Jeremy Moles
Hello everyone! I'm running into a problem in my application where I'm 
trying to switch between two different subgraphs as the result of some 
event (key press or similar). The first of these two objects is a 
standard subgraph with nothing too sophisticated going on. The second of 
these is a RTT stack of Camera objects.


The problem manifests in that if I switch FROM the standard graph (just 
a random grouping of models) to the RTT Camera stack, the bounds of the 
previous node are used for the RTT Camera. This means that while the 
same scene rendered within my RTT stack is fine as long as you don't 
adjust the view matrix, as soon as you move the scene around it begins 
to get culled. I can remedy this problem by disabling culling on the 
main viewer camera when my RTT stack is in effect, but I feel like I'm 
doing something wrong... the reason I think this is because I can add 
the RTT stack to my scene as the FIRST scene (and never toggle it to 
anything else) and the culling occurs correctly. The problem only 
manifests when I switch from the RTT stack to a standard node AND THE 
BACK to the RTT scene.


Has anyone tried anything like this in the past? Does anyone have any 
hints? :)

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


Re: [osg-users] Raspberry pi

2013-05-14 Thread Jeremy Moles

On 05/14/2013 04:47 AM, Bruno Ronzani wrote:

Hi Jeremy,

Very cool indeed ! Thank you for adding the pre-compiled OSG too ;)

I just needed a quick example to test everything out.

If I can show that OSG works fine - means at least 30fps, with image rendering, 
interactions and movements - on the PI, I will probably get the time and money 
to do the devs you are talking about :) (it still seems to me very optimistic 
though)

On your example, there is no working input (keyboard, mouse), right ?

In the example I've posted in my last message, the guy was using the SDL to get 
them. Maybe I should do the same ?
In Linux, you use the kernel's evdev API (/usr/include/linux/input.h) 
and read input_event structures one at a time from the appropriate 
device node in /dev/input. Evdev is documented thoroughly on the web, so 
a quick google search will reveal everything you need to know. The API 
is simple and easy to use.


SDL may have some wrapper around it, but using the RPi it's very likely 
you'll have some custom input device being developed with your final 
product, so knowing how to use evdev directly (which is really just a 
lunch-break research project) is useful.

Thanks again,

Bruno

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





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



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


Re: [osg-users] Raspberry pi

2013-05-13 Thread Jeremy Moles

Take a look at this little project I started:

http://osgrpi.googlecode.com

I'm not done polishing things up (and I don't even use X11 at all here), 
but those kinds of things could be resolved with the right time/money. :)


I would imagine that for most people want to use the RPi and OSG, X wont 
actually be desired. They'll like have some other embedded form of 
input (like a 9DOF mems device, a Kinect, etc.), but who knows. There 
are lots of paths for adding more traditional OSG support...


1) Write a new osgViewer::GraphicsWindow object. This would be good for 
the short-term, but would be hardly better than the EmbeddedViewer code.


2) Write (or wait for someone to write) a proper DRI driver for X for 
the Broadcom/VideoCore device. This would let us just the standard X11 
GraphicsWindow, without caring one way or another.


On 05/13/2013 12:01 PM, Bruno Ronzani wrote:

Hi,

I haven't found anything recent about making OpenSceneGraph work on a Raspberry 
Pi.

This example (nothing to do with OSG) works quite well, without X11 : 
https://bitbucket.org/benedek/rpi-simple-paramplot/overview

Anyone tried something (maybe not) similar with OSG on a Pi ?

Would be very nice to have our favorite scene graph working on this great 
little thing ;)

Cheers,

Bruno

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





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



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


Re: [osg-users] osgWidget::EventInterface possible memory leak

2013-04-15 Thread Jeremy Moles

On 04/15/2013 12:37 PM, Judson Weissert wrote:

Hello,

I have been experimenting with the osgWidget library recently, and 
came across what I believe to be a memory leak. I added a break point 
to the osgWidget::Callback destructor, and it is never called when 
running the osgwidgetcanvas example program (the constructor is called 
a number of times).


The osgWidget::EventInterface::CallbackList typedef line in 
osg/include/osgWidget/EventInterface is:


typedef std::listosg::observer_ptrCallback  CallbackList;

Therefore, the osgWidget::EventInterface object is not managing the 
callback's memory. Clients could make the mistake of passing in a 
temporary ref_ptr which would then go out of scope before the callback 
is used, or if the client passes in an unmanaged pointer (like in the 
osgWidget examples), there will be a memory leak unless the caller 
explicitly deallocates the callback at some point in the future after 
the callback is no longer associated with the scene.


Should the CallbackList type be a std::list osg::ref_ptr Callback 
instead?


I just checked this as well, and you appear to be correct. I'm trying to 
remember what the INTENTION was, but its been so long I can't recall.

Thanks,

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



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


Re: [osg-users] What's the progress of osgPango?

2013-04-03 Thread Jeremy Moles

On 04/03/2013 09:20 AM, michael kapelko wrote:

Hi.
I've been researching Cairo / Pango for GUI use with OSG, and googled 
this up:

http://forum.openscenegraph.org/viewtopic.php?t=6394

The osgPango page ( http://code.google.com/p/osgpango/ ) says:

Screenshots
COMING BACK SOON (August, 2012)

I don't have anywhere to put them, I stopped paying for my Linode 
account since I never really used it.


osgPango and osgCairo both work just fine (I just used them in some paid 
work, actually). However, I've been wanting to use Harfbuzz instead 
(Pango is built on Harfbuzz), but haven't had a chance to yet. Like 
Chris said, very busy.

I wonder how's osgPango doing?
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


Re: [osg-users] changing a osgWidget::Box position

2013-03-15 Thread Jeremy Moles

On 03/14/2013 12:14 PM, Aitor Ardanza wrote:

Hi,

I don't understand the Jeremy answer... when you say call update() function, 
you are refering to osgWidget::Box update?

I need to reposition some GUI box when the window is resized. If I call..

void HyperPatientVRGUI::resize(int w, int h)
{
  _hyperLogoBox-setPosition(0.0f, h-500, 0.0f);
  _hyperLogoBox-update();
 .
}
I imagine that since you're setting the Z value here, you're just 
causing it to go out of your projection. Try just using setOrigin(), 
instead.

hyperLogoBox disapears...

Thank you!

Cheers,
Aitor

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





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



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


Re: [osg-users] osgWidget Frame borders

2013-03-15 Thread Jeremy Moles

On 03/15/2013 12:42 AM, Alexandre Valdetaro wrote:

I am having this same problem here. Did anyone find a solution for it? Does 
anyone not have this problem?

I'll take a look later today and see if I can't figure out what is going on.

Thanks,
Alex

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





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



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


Re: [osg-users] Fedora 18 with nVidia driver: OSG crashes session

2013-02-01 Thread Jeremy Moles

On 01/31/2013 04:30 PM, Stuart Mentzer wrote:

Hi Robert,

You were right: the problem was broader than OSG. The fix was to modify 
/etc/X11/xorg.conf so that these 2 lines were in the Files section:


Code:
Section Files
 ModulePath /usr/lib64/nvidia/xorg
 ModulePath /usr/lib64/xorg/modules
EndSection


(Sorry I just saw this thread...)

You could also put that little blurb somewhere in 
/usr/share/X11/xorg.conf.d, since a static xorg.conf isn't as flexible.


I should note that I also use Fedora 18 exclusively, and I do it with no 
problems at all. I use two different builds of OSG, one of which uses my 
Intel card/GLES2-only and another which is routed through Bumblebee and 
uses the NVidia optimus technology on my T410. All of this works 
flawlessly, and I even get about 3-5 hours of battery life, depending on 
how hard I'm pushing the machine.


Of course, this could have something to do with working for a company 
whose sole purpose is to put Linux on laptops and make them work well, 
but. :)


(Another interesting note: when we install the NVidia drivers here on 
our machines, we don't even run the binary they provide; we just extract 
it into /opt/emperor, touch a few configs to add the appropriate library 
paths, and configure bumblebee to search the right directories; no 
existing RPM files are modified, as it is our policy to avoid futzing 
with the core in any way...)



This comes from http://forums.fedoraforum.org/showthread.php?p=1626150

I hope this helps some other F18 users (until this bug is fixed).

Cheers,
Stuart

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





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



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


Re: [osg-users] Linear gradient color in osgnvpr

2013-01-17 Thread Jeremy Moles

On 01/17/2013 03:57 AM, Serkan Ozkaymak wrote:

Hi,

Is linear gradient color supported by osgnvpr ?
This is easy to do, but I don't know if I got around to doing it quite 
yet. Hit me up on googletalk if you need to know more.

Thank you!

Cheers,
Serkan

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





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



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


Re: [osg-users] Which GPGPU postprocessing method is best for me?

2013-01-04 Thread Jeremy Moles

On 01/04/2013 09:33 AM, Ethan Fahy wrote:

Hello all,

I have an osg project that uses shaders to write float32 values representing 
temperatures to my framebuffer texture.  I would like insert a CUDA or OpenCL 
kernel to take those temperature values in the framebuffer and reinterpret them 
as colors based on various sensor effects.

My current understanding is that I may be able to accomplish this in 3 ways:
1.  osgPPU
2.  osgCompute/osgCUDA
3.  write something myself from scratch somehow...
Wang Rui is (I believe) in a Chinese time zone, but he may chime in here 
later today.


He is working on osgFX::EffectsCompositor, which I personally found 
incredibly well-written and easy-to-use.


Check out his code here:

https://github.com/xarray/osgRecipes

I have spent a day or so reading through the documentation and forums for both 
osgPPU and osgCompute but I'm wondering if anybody might have suggestions for 
my particular use case so I optimize my research time.  As always my many 
thanks.

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





___
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] Coursera Classes Coming Up!

2013-01-02 Thread Jeremy Moles

Hey guys!

You've probably heard by now, but there is a really great up-and-coming 
website/organization/movement called Coursera that I learned about last 
year.


http://www.coursera.org
https://www.coursera.org/user/i/cec974e9434316ce7625ee9df772effe

There are some REALLY great math and graphics classes that start in the 
next few days, and I wanted to see if anyone was going to be taking the 
same classes as myself. Perhaps we could work together over Jabber and 
form a kind of study group. :)


Anyways, hope you all had as great a 2012 as myself! Here's to another 
great one!


P. S. All of our resolutions should be, henceforth, to never use the 
OpenGL FFP ever again!

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


Re: [osg-users] GLES2/Trigonometry Question

2012-12-07 Thread Jeremy Moles

On 12/07/2012 12:27 PM, Paul Martz wrote:
(Sorry if this shows up twice; I originally posted it Tuesday but it 
has not echoed back to the list. Test emails seem to work, so trying 
again...)


Hi Jeremy -- Since you know the FOV in y (it's 45.0 degrees), you can 
compute the distance to fit a bounding sphere with the following code:


double computeInitialDistanceFromFOVY( const osg::BoundingSphere bs, 
const double fovy )

{
return( bs.radius() / sin( osg::DegreesToRadians( fovy * .5 ) ) );
}

That code comes from the matrix utility library (osgwMx) in the 
osgWorks project, but equivalent code exists in osgGA to compute home 
positions, which you could also use as a reference.

   -Paul



Cool, thanks!

Chris Hanson explained this to me off the lists, as well. It's actually 
REALLY simple trig, but for whatever reason I just haven't ever thought 
of 3D math as anything other than voodoo magic.


Now, of course, it makes perfect sense, and I honestly think I've 
acquired a whole new perspective at solving problems in graphics 
mathmatically. I even went and picked myself up a trig/calc book at BN 
to worth through over the next few weeks.


On 12/4/2012 7:47 AM, Jeremy Moles wrote:
Hello everyone! I'm writing a bit of code using parts of OSG and pure 
OpenGLES2.
This isn't exactly an OSG question, per se, but there are a lot of 
OpenGL

experts here and this is a great resource. :) Any help is appreciated!

In my particular scene, I do not maintain a matrix representing my 
camera;
there is a global projection matrix and each Drawable maintains its 
own model
matrix. For this reason, whether pedantically right or wrong, I say 
that my

camera always sits at 0, 0, 0 and looks into a frustum created using the
equivalent of gluPerspective(45, 1, 1, 100).

What I'm looking for is the trigonometric calculation that would 
allow me to
determine either the Z value to translate my scene or the scale to 
apply to my

scene in order to fit the entire thing cleanly into my viewport.

I have both the osg::BoundingBox and osg::BoundingSphere of my scene, 
but since
I'm not using a camera manipulator or view matrix directly, I can't 
simply

reference the code in CameraManipulator.cpp.

Furthermore: I have this working currentls in a VERY TERRIBLE way. :) 
What I do

is use reimplementations of gluProject and gluUnproject to caclulate
screen-to-world and world-to-screen coordinates. I then use those 
values to
figure out how much to scale my scene by, but this feels so wrong 
(and bound to

a known window size) that I know there must be a better way.

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://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] GLES2/Trigonometry Question

2012-12-04 Thread Jeremy Moles
Hello everyone! I'm writing a bit of code using parts of OSG and pure 
OpenGLES2. This isn't exactly an OSG question, per se, but there are a 
lot of OpenGL experts here and this is a great resource. :) Any help is 
appreciated!


In my particular scene, I do not maintain a matrix representing my 
camera; there is a global projection matrix and each Drawable 
maintains its own model matrix. For this reason, whether pedantically 
right or wrong, I say that my camera always sits at 0, 0, 0 and looks 
into a frustum created using the equivalent of gluPerspective(45, 1, 1, 
100).


What I'm looking for is the trigonometric calculation that would allow 
me to determine either the Z value to translate my scene or the scale to 
apply to my scene in order to fit the entire thing cleanly into my viewport.


I have both the osg::BoundingBox and osg::BoundingSphere of my scene, 
but since I'm not using a camera manipulator or view matrix directly, I 
can't simply reference the code in CameraManipulator.cpp.


Furthermore: I have this working currentls in a VERY TERRIBLE way. :) 
What I do is use reimplementations of gluProject and gluUnproject to 
caclulate screen-to-world and world-to-screen coordinates. I then use 
those values to figure out how much to scale my scene by, but this feels 
so wrong (and bound to a known window size) that I know there must be a 
better way.


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


[osg-users] Status of Collada Reader (November, 2012)

2012-11-20 Thread Jeremy Moles
Hey guys--anyone using OSG with the Collada reader on Linux? Although I 
doubt this is a Linux-centric issue.


I've tried the 2.2 (won't even build), 2.3 and 2.4 (neither of which 
work with the OSG code) to no avail. Is there something obvious I'm 
missing here?


The wiki indicates I should use the 2.2 DOM, but that won't even build 
on its own; something about missing domAsset.h, which doesn't even exist 
in the 1.4 tree. It exists in 1.5, but our plugin doesn't work with that 
yet.


Just looking for some additional info before I give up. :)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Status of Collada Reader (November, 2012)

2012-11-20 Thread Jeremy Moles

On 11/20/2012 01:50 PM, Jason Daly wrote:

On 11/20/2012 09:50 AM, Jeremy Moles wrote:

Hey guys--anyone using OSG with the Collada reader on Linux? Although I
doubt this is a Linux-centric issue.

I've tried the 2.2 (won't even build), 2.3 and 2.4 (neither of which
work with the OSG code) to no avail. Is there something obvious I'm
missing here?

The wiki indicates I should use the 2.2 DOM, but that won't even build
on its own; something about missing domAsset.h, which doesn't even exist
in the 1.4 tree. It exists in 1.5, but our plugin doesn't work with that
yet.


I don't use it regularly, but I do have OSG compiled with the 2.2 
DOM.  I just tested it (osgviewer on a .dae file), and it still seems 
to be working.


I do remember a little bit of pain in getting the 2.2 DOM to compile, 
but I don't recall the details.  I do remember that I only built the 
dom directory (I don't use Cg, so I skipped the fx directory, and I 
didn't care about the viewer or rt features).


For what it's worth, my copy of the 2.2 DOM does have a 
dom/include/1.4/dom/domAsset.h file.



The versions available at the moment do not. I wonder what the deal is... :/

--J

___
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] OSG + RaspberryPi

2012-10-31 Thread Jeremy Moles
Has anyone had the chance to play with OSG on the RaspberryPi? I have a 
number of OpenGLES2 examples working using their Broadcom VideoCore 
API and I intend on trying to put together a simple 
GraphicsWindowRPi.cpp implementation later today.


I just wanted to quickly ping the lists and see if anyone else had tried 
this and what their experience was.


My intention is to interface with their VideoCore API (which doesn't 
require Xorg) at first. I'm sure in the coming months, with Broadcom 
having recently opensourced their userspace implementations of libGLES 
and whatnot, more appropriate Xorg/DRI driver will likely come into 
being. However, in the meantime, this should be a quick and easy (though 
inputless!) approach...

___
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

2012-09-17 Thread Jeremy Moles
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.

Hi Wang,

Did you ever get a chance to work up an example showing something like
this? I've been trying to get it to work using a modified blur-x/blur-y
approach from osgPPU, but have had no success.

 Thanks,
 
 Wang Rui
 
 2012/9/11 Jeremy Moles cubic...@gmail.com:
  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


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

2012-09-11 Thread Jeremy Moles
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 cubic...@gmail.com:
  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


Re: [osg-users] Check if a Drawable was culled or not

2012-09-11 Thread Jeremy Moles
On Tue, 2012-09-11 at 16:52 +0200, Janna Terde wrote:
 Hi,
 
 I have a scene containing several mirrors but I would only like to enable RTT 
 camera if the node representing a mirror is visible. I am trying to check  if 
 the specific Drawable was culled or not but so far I was not getting the 
 results I wanted. 
 Before getting into details on how I am trying to do it, I wonder if someone 
 can suggest me a simple way to do such check?

If I'm not mistaken, this is already the default behavior. In fact, I
was under the impression that the recommended way to even disable RTT
in the first place was to simply have it automatically culled via it's
NodeMask.

What would you be doing differently in order to enable/disable RTT?

P. S. This is just what I think. I could be wrong, and hopefully
someone will chime in and prevent me spreading misinformation if I
am. :)

 Thank you very much! :)
 
 Cheers,
 Janna
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=49931#49931
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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


Re: [osg-users] Check if a Drawable was culled or not

2012-09-11 Thread Jeremy Moles
On Tue, 2012-09-11 at 20:36 +0200, Janna Terde wrote:
 Hi Jeremy,
 
 I can cull the RTT camera using its cull mask or node mask however I need to 
 know when should I do it. I would like to cull the camera when the node 
 representing the mirror (Geode) is culled so when it is outside of the 
 viewing frustum. This is what I am trying to do, I've tried to use 
 CullVisitor and isCulled function and also tried to construct the Polytope 
 from main camera but still did not get the correct behavior.   :(

OH RIGHT. Good point, a kind of chicken-and-egg problem. :)

Try this, and I'll try it to as soon as I can: create a CullCallback
that calls isCullingActive(); if so, set NodeMask to something wonky.
Attach the CullCallback to your Geode.

(This is just from a cursory look at the API and from experience, I'll
try it soon...)

 So I am wondering if there is something I don't know since it seems to be 
 very common thing to do and should be simple to do. 
 
 Cheers,
 Janna
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=49946#49946
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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


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

2012-09-10 Thread Jeremy Moles
On Mon, 2012-09-10 at 22:57 +0800, Wang Rui wrote:
 Hi all,
 
 Just to announce that the material system is still in progress and
 I've just made the first version for myself to test and use. An
 optimized version with a complete deferred shading pipeline (XML
 files) will be submitted if it could fit most requirements.
 
 As to share my current work with anyone who are also interested in
 this idea and implementations, I'd like to attach the source files
 along with this mail instead of submitting it in full fling. If you do
 have better ideas, think the work is misdirected or needs to be fixed
 in some parts, please don't hesitate to tell me. A second version with
 more test files and a detailed XML file introduction will be updated
 soon after some days.
 
 Thanks,

I'm testing this out, but you appear to have left noise_tex.jpg out of
the zip. :)

 Wang Rui
 
 
 2012/6/21 Wang Rui wangra...@gmail.com:
  Hi Robert, hi all,
 
  During the past few days, I was thinking of implementing a resource system,
  as well as a rendering structure which could support both forward and
  deferred rendering for OSG. This could help developers design complex
  materials and effects, test cutting-edge GPU techniques, and implement
  multi-pass / deferred rendering pipelines with user-friendly interfaces or
  even a readable script format. Similar work were already done in some game
  engines like Ogre3D, CryEngine and Unreal, and I now plan to work out
  something with the same power and can fit our OSG users much better. :-)
 
  My initial thoughts are:
  1. A resource system records all the resource used in the rendering
  pipeline, including textures, state attributes, shaders, uniforms, camera
  parameters, and semantics (not used in GLSL, but very useful IMHO). Resource
  can be referred by other resource, or obtained from APIs to be altered. It
  can be recorded in an XML-based format for reading/writing, and external
  uses.
  2. A rendering framework uses one or more techniques, passes, and connect
  their inputs/outputs for complex render work. It can also be recorded by the
  resource system and is implemented as a group node in the scene graph, which
  performs actual forward/deferred rendering work.
  3. Some in-built techniques and passes can help implement some complex
  effects on customized scene quickly. Common ones I planned include HDR,
  SSDO, godrays, depth of field, motion blur, lensflare, color grading and
  FXAA. A benchmark could be developed first to show how the framework works.
  4. Reader/writers could be developed then to convert DAE, CGFX, or even
  other game engine scripts into OSG native rendering pipelines, which will
  greatly help migrations from other engines.
 
  The resource system itself is actually abstract and can be extended to
  contain whole scene information later, so it could be placed in the osgDB
  library. And the new rendering pipeline, which can totally replace current
  osgFX functionlities, can be placed in osgFX and rendering resource
  management will be done here, too.
 
  I'm glad to work with others who has interests in such an idea, and hope an
  initial version could be finished before OSG 3.2. For the first stage I will
  borrow some code from the osgPostEffects library in my experimental osgXI
  project, to quickly build the low-level APIs of the framework. But anyone
  who have better ideas, or could contribute some code or effects will be
  really appreciated.
 
  Cheers,
 
  Wang Rui
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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


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

2012-09-10 Thread Jeremy Moles
On Mon, 2012-09-10 at 22:57 +0800, Wang Rui wrote:
 Hi all,
 
 Just to announce that the material system is still in progress and
 I've just made the first version for myself to test and use. An
 optimized version with a complete deferred shading pipeline (XML
 files) will be submitted if it could fit most requirements.
 
 As to share my current work with anyone who are also interested in
 this idea and implementations, I'd like to attach the source files
 along with this mail instead of submitting it in full fling. If you do
 have better ideas, think the work is misdirected or needs to be fixed
 in some parts, please don't hesitate to tell me. A second version with
 more test files and a detailed XML file introduction will be updated
 soon after some days.

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. :)

 Thanks,
 
 Wang Rui
 
 
 2012/6/21 Wang Rui wangra...@gmail.com:
  Hi Robert, hi all,
 
  During the past few days, I was thinking of implementing a resource system,
  as well as a rendering structure which could support both forward and
  deferred rendering for OSG. This could help developers design complex
  materials and effects, test cutting-edge GPU techniques, and implement
  multi-pass / deferred rendering pipelines with user-friendly interfaces or
  even a readable script format. Similar work were already done in some game
  engines like Ogre3D, CryEngine and Unreal, and I now plan to work out
  something with the same power and can fit our OSG users much better. :-)
 
  My initial thoughts are:
  1. A resource system records all the resource used in the rendering
  pipeline, including textures, state attributes, shaders, uniforms, camera
  parameters, and semantics (not used in GLSL, but very useful IMHO). Resource
  can be referred by other resource, or obtained from APIs to be altered. It
  can be recorded in an XML-based format for reading/writing, and external
  uses.
  2. A rendering framework uses one or more techniques, passes, and connect
  their inputs/outputs for complex render work. It can also be recorded by the
  resource system and is implemented as a group node in the scene graph, which
  performs actual forward/deferred rendering work.
  3. Some in-built techniques and passes can help implement some complex
  effects on customized scene quickly. Common ones I planned include HDR,
  SSDO, godrays, depth of field, motion blur, lensflare, color grading and
  FXAA. A benchmark could be developed first to show how the framework works.
  4. Reader/writers could be developed then to convert DAE, CGFX, or even
  other game engine scripts into OSG native rendering pipelines, which will
  greatly help migrations from other engines.
 
  The resource system itself is actually abstract and can be extended to
  contain whole scene information later, so it could be placed in the osgDB
  library. And the new rendering pipeline, which can totally replace current
  osgFX functionlities, can be placed in osgFX and rendering resource
  management will be done here, too.
 
  I'm glad to work with others who has interests in such an idea, and hope an
  initial version could be finished before OSG 3.2. For the first stage I will
  borrow some code from the osgPostEffects library in my experimental osgXI
  project, to quickly build the low-level APIs of the framework. But anyone
  who have better ideas, or could contribute some code or effects will be
  really appreciated.
 
  Cheers,
 
  Wang Rui
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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


Re: [osg-users] Looking For An osgPPU RTT Example

2012-09-07 Thread Jeremy Moles
On Fri, 2012-09-07 at 13:39 +0400, Sergey Polischuk wrote:
 Hi
 
 If you mean output to texture attached to fbo it works for me without any 
 problems. At the end of pipeline you just create osgPPU::UnitOut with output 
 texture set to your fbo attachment texture. Also IIRC you should add your 
 processor to main scene graph (viewer-getSceneData() ) or to viewer camera 
 even if you processing nested camera output.

I didn't see any methods of UnitOut that allowed this, but I did happen
to find a UnitTexture object (that is used the movie example, I somehow
missed) which I will experiment with.

Thanks for the nudge. :)

 Cheers.
 
 07.09.2012, 00:25, Jeremy Moles cubic...@gmail.com:
  Hey guys, I'm looking for some osgPPU example code demonstrating setting
  up an osgPPU pipeline ONLY on an FBO texture. All of the examples in the
  project currently--at least, as far as I can tell--appear to always use
  the Viewer's Camera directly, which won't work for my use.
 
  Futhermore, all of my own personal attempts to implement this result in
  some really crazy results; for example, creating a black, null Viewport
  inside my SceneGraph with no seeming purpose.
 
  I haven't seen much traffic from Art Tevs lately, so if there's an
  alternative to osgPPU, I'd be willing to try that out too.
 
  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://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] Looking For An osgPPU RTT Example

2012-09-06 Thread Jeremy Moles
Hey guys, I'm looking for some osgPPU example code demonstrating setting
up an osgPPU pipeline ONLY on an FBO texture. All of the examples in the
project currently--at least, as far as I can tell--appear to always use
the Viewer's Camera directly, which won't work for my use.

Futhermore, all of my own personal attempts to implement this result in
some really crazy results; for example, creating a black, null Viewport
inside my SceneGraph with no seeming purpose.

I haven't seen much traffic from Art Tevs lately, so if there's an
alternative to osgPPU, I'd be willing to try that out too.

Thanks!

___
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

2012-09-05 Thread Jeremy Moles
On Tue, 2012-09-04 at 19:21 +0100, Robert Osfield wrote:
 Hi Jeremy,
 
 It should be possible to do a
 
 drawImplementation(..)
 {
 
   state.apply(stateSetOne);
   // do stuff
   state.apply(stateSetTwo);
  // do more stuff
 
 }

I've settled on:

drawImplementation() {
state.pushStateSet(ss1);
state.apply();
// do stuff
state.popStateSet();
state.apply()

state.pushStateSet(ss1);
state.apply();
// do more stuff
state.popStateSet();
state.apply()
}

Does this seem like an abomination? :) Just calling state.apply() ALMOST
worked, but there was some state leakage (for example, the shader was
applied to all subsequent fragment processing, regardless of it's
location in the graph).

 I'm not 100% sure what will happen with the progress of draw traversal
 w.r.t how the drawable StateSet if any is applied and then later
 assumed to be applied by other state calls.  I think it will probably
 work out OK though so try it, and if something breaks then considering
 adding an extra state.apply(drawwablesStateSet) or a perhaps a state
 dirty.
 
 This is something we can workout if required though, try the simplest
 thing first then if need be investigate more complicated routes...
 
 Robert.
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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


[osg-users] Custom Drawable GLSL

2012-09-04 Thread Jeremy Moles
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


Re: [osg-users] Custom Drawable GLSL

2012-09-04 Thread Jeremy Moles
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


Re: [osg-users] Custom Drawable GLSL

2012-09-04 Thread Jeremy Moles
On Tue, 2012-09-04 at 19:15 -0400, Jean-Sébastien Guay wrote:
 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,

Hey Paul. :)

It's not simply an issue of setting two similar state attributes in
sequence; the NV_path_rendering API is different enough in that for the
stroke you may want to use a shader and for the fill you may want to
reset the state and use whatever fixed state was available previously,
which is why I've had the issues. HOWEVER, I could just implement
everything as shaders anyways.

What I really seem to need is like a State::save(), State::restore()
kind of thing...

 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
 
 
 


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


Re: [osg-users] [ANN] osgAndroid: Library for develop OSG applications in Android

2012-08-30 Thread Jeremy Moles
On Thu, 2012-08-30 at 14:02 +0200, Rafa Gaitan wrote:
 Hi everybody,
 
 
 I'm glad to announce osgAndroid (OpenSceneGraph for Android). It
 consists in a set of Java/JNI wrappers of OpenSceneGraph and some
 helper classes to easily develop OSG applications in Android.

Just out of curiosity, does this avoid the need to enable untrusted
software sources or whatever it is Android calls it?

 
 The code repository is hosted in Gitorious:
 
 
 https://gitorious.org/osgandroid
 
 
 I still don't have a complete documentation, but some
 quick start guidelines can be found here:
 
 
 https://gitorious.org/osgandroid/pages/Home
 
 The osgAndroid project has been initially funded by:
 
 IRTIC(http://smagris3.uv.es/irtic/)
 AI2(http://www.ai2.upv.es)
 MirageTechnologies S.L.(http://www.mirage-tech.com).
 
 
 But we all agreed in open the source code and try to make the life
 easier to all osg developers that want to migrate applications to
 Android. The project was initially developed with AR applications in
 mind, so you will not find too many interaction tools there, and of
 course has some limitations, but you can load and display a model with
 only a few lines of code:
 
 
 ... 
 mView = new Viewer(this);
 mView.init(false, 16, 8);
 mView.setSceneData(ReadFile.readNodeFile(/sdcard/axes.ive));
 mView.setDefaultSettings();
 setContentView(mView);
 ...
 
 
 Some usage samples can also be found in the code, such as how to use
 the Android device Camera with an OSG scene with transparent
 background or how to mix osgAndroid and native code in an Android
 Activity, and much more will be added.
 
 
 I would also like to announce the project in the community news
 section of the new site (openscenegraph.com), is it possible?
 
 
 I really hope this will be useful to the community, and of course feel
 free to contribute!
 
 
 Cheers,
 Rafa
 
 
 
 
 
 -- 
 Rafael Gaitán Linares
 CTO at Mirage Technologies S.L - http://www.mirage-tech.com
 gvSIG3D Developer - http://gvsig3d.blogspot.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


Re: [osg-users] [3rdparty] osgWidget and rotation

2012-08-28 Thread Jeremy Moles
On Tue, 2012-08-28 at 11:05 +0200, Miguel Lokida wrote:
 Hi,
 
 I want to use an osgWidget to draw a compass. So, I need to use the rotation. 
 The problem is that the origin of the osgWidget is at the bottom left and not 
 at the center of the widget. 
 
 How can I specify the center of my widget (since set Origin only move the 
 widget) in order to have a good rotation.

A Widget's origin should be relative to the Window it is parented in.
Rotations should occur properly in that respect, can you provide some
code that isn't behaving properly?

 Thank you!
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=49609#49609
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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


Re: [osg-users] [3rdparty] osgWidget and rotation

2012-08-28 Thread Jeremy Moles
On Tue, 2012-08-28 at 16:59 +0200, Miguel Lokida wrote:
 So i see what you mean. But how can I declare the position of my widget 
 relative to the parented window ?
 
 Here's the code I use:
 
 [code]
 const unsigned int MASK_2D = 0xF000;
 
 // note: osgViewer::Viewer* ptrViewer;
 // note: osg::ref_ptrosg::Group _rootScene;
 // note: ptrViewer-setSceneData(_rootScene);
 
 osgWidget::WindowManager* wm = new osgWidget::WindowManager( 
   ptrViewer,
   ptrViewer-width(),
   ptrViewer-height(),
   MASK_2D,
   osgWidget::WindowManager::WM_PICK_DEBUG
  );
 
 osgWidget::Window* box = new osgWidget::Box(HBOX, osgWidget::Box::VERTICAL, 
 true);
 
 osgWidget::Widget * testWidget = new osgWidget::Widget(test, 100.0f, 
 100.0f);
 testWidget-setColor(1, 0, 0, 1.0);
 box-addWidget(testWidget);
 
 //box-setAnchorHorizontal(osgWidget::Window::HA_RIGHT);
 //box-setAnchorVertical(osgWidget::Window::VA_TOP);
 
 box-setVisibilityMode(osgWidget::Window::VM_ENTIRE);
 
 wm-addChild(box);
 
 // rotation
 box-setRotate(45.0);
 
 osg::Group*  group  = new osg::Group();
 osg::Camera* camera = wm-createParentOrthoCamera();
 
 _rootScene-addChild(camera);
 
 wm-resizeAllWindows();
  
 [/code]
 
 may be I am wrong with this code ?

I've done some testing and you aren't really doing anything wrong here;
it is simply a weakness in osgWidget I never thought of. I'm not sure
how to best proceed, but you have at least two reasonable options:

1) An osgWidget::Window is a MatrixTransform, and an osgWidget::Widget
is just an osg::Geometry. You could attach an
osg::Drawable::UpdateCallback to your widget, but you'd need to do some
fancy calculations to get it to rotate in place. I tried quickly doing
this, but couldn't get the math right in the few minutes I had to test
it... I've attached this code, but you'll need to fix it to make it
work.

2) Create one Window for your compass outline and another for your
compass spinner; add the spinner to the outline and call setRotate() on
the spinner window as needed.

In the long run, osgWidget should be rewritten to be more modern and use
my (and utilizing feedback from the community) improved understanding of
OSG in general. Alas, the bills don't stop coming, and the little free
time I have (I do Linux development as my 40+/week) goes to the
occasional contract I can secure or other such activities.

I would really like to go back and fix all the things I know are wrong,
I just need a solid, uninterrupted 2 weeks to do so. :)

 Thanks !
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=49635#49635
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

#include osg/io_utils
#include osgDB/ReadFile
#include osgWidget/Util
#include osgWidget/WindowManager
#include osgWidget/Box

const unsigned int MASK_2D = 0xF000;

class SpinnerCallback: public osg::Drawable::UpdateCallback {
	virtual void update(osg::NodeVisitor* nv, osg::Drawable* drawable) {
		static osg::Matrix::value_type r = 0.0f;
		static double  t = 0.0f;
		
		double time = nv-getFrameStamp()-getSimulationTime();

		if(time - t  0.1f) {
			r += 1.0f;
			t  = time;

			OSG_WARN  r  std::endl;

			osgWidget::Widget* widget = dynamic_castosgWidget::Widget*(drawable);
			osgWidget::PointArray* points = dynamic_castosgWidget::PointArray*(widget-getVertexArray());

			osg::Matrix rotate= osg::Matrix::rotate(osg::DegreesToRadians(r), osg::Vec3(0.0f, 0.0f, 1.0f));
			osg::Matrix translate = osg::Matrix::translate(osg::Vec3(0.0f, 0.0f, 0.0f));

			for(
osgWidget::PointArray::iterator i = points-begin();
i != points-end();
i++
			) {
*i = rotate * translate * *i;
			}
		}
	}
};

int main(int argc, char** argv) {
	osgViewer::Viewer viewer;

	osgWidget::WindowManager* wm = new osgWidget::WindowManager(
		viewer,
		640.0f,
		480.0f,
		MASK_2D,
		osgWidget::WindowManager::WM_PICK_DEBUG
	);

	osgWidget::Box*outline = new osgWidget::Box(Outline, osgWidget::Box::VERTICAL, true);
	osgWidget::Widget* spinner = new osgWidget::Widget(Spinner, 100.0f, 100.0f);

	spinner-setPadding(100.0f);
	spinner-setColor(1.0f, 0.0f, 0.0f, 1.0f);
	spinner-setUpdateCallback(new SpinnerCallback());

	outline-addWidget(spinner);
	outline-getBackground()-setColor(1.0f, 1.0f, 1.0f, 1.0f);
	outline-attachMoveCallback();

	wm-addChild(outline);

	return osgWidget::createExample(viewer, wm);
}

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


[osg-users] Chicken Egg Problem: BoundingBoxes

2012-08-27 Thread Jeremy Moles
Hello all!

I'm working on a NodeKit (that is coming along nicely, btw) for using
the NVidia NV_path_rendering extension with OSG. This new extension has
an interesting--and, AFAIK, hitherto unseen--rendering model.

When using NV_path_rendering (which I will call NVPR), one must feed
path coordinate data into the OpenGL driver and it will compile this
data for you into resources the graphics context identifies by number.
This work fairly well in OSG using the Drawable override of
compileGLObjects(), since I am given a valid and active graphics context
which I can use to build the renderable objects.

(As a side node, for the uninitiated, a path in this context is a
N-order series of 2D coordinates that you use to draw vectors graphics;
for example, fonts. NVPR is an extension that uses your Cuda cores to
drastically speed this process up and create incredibly fast and
high-quality 2D graphics.)

I mentioned earlier that compiling these objects and making them
available to OSG (even as displayLists) is straightforward. HOWEVER,
there is an issue with regards to properly informing OSG of the bounding
boxes of these objects, a kind of chicken-and-egg problem. :)

Up until now, Drawable objects in OSG have had some kind of 3D geometric
data associated with them. This lets the object calculate the bounding
box on the CPU as the object is created, and inform the scenegraph
almost immediately what to expect with regards to its bounds. In NVPR,
we need the GPU to compute these bounds, but it cannot do so until AFTER
it has compiled the objects internally. This means it needs a valid
graphics context an should ideally do so towards the end of the
compileGLObjects method. As before, this is straightforward to execute,
but the order of operations here makes things tricky with OSG.

Consider the following:

osg::Geode*g = new osg::Geode();
osgNVPR::Path* p = new osg::PathCommands();

p-doStuff();

g-addDrawable(p);
// DOH! OSG wants to do bounding calculations here, but we
// haven't yet compiled or calculated the path internally
// until compileGLObjects is called!

I've come up with some workarounds, such as calling:

viewer.realize();
viewer.frame();

...and then manually calling dirtyBound(), but these feels very wrong to
me.

I wanted to quickly as the OSG community if they had any advice on how I
should best approach this problem. Drawble::dirtyBound() isn't a const
method, and so can't be easily called from compileGLObjects.

Perhaps there may be some way to pre-compile these paths with a valid
rendering context shortly after creating the Viewer?

At any rate, hope everyone has a great week! LABOR DAY EXTENDED WEEKEND!

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


Re: [osg-users] Chicken Egg Problem: BoundingBoxes

2012-08-27 Thread Jeremy Moles
On Mon, 2012-08-27 at 16:50 +0100, Robert Osfield wrote:
 Hi Jeremy,
 
 The OSG uses a compile traversal that is called on the first frame of
 rendering (Renderer.cpp's Renderer::compile() method) and this will
 call your Drawable::compileGLObjects(), this can then set the dirty
 bound so that on the next cull traversal it'll update bounding box
 automatically for you.  The other thing to do would be to estimate the

This isn't currently possible because of the dirtyBound() prototypes on
Drawable and Node (they are not const). However, if this is an API
change you'd be agreeable to, I'd be happy to submit it. :)

 bounding box based on the input parameters to your Drawable, or let
 the use define this or leave it up to the compile method.

 Robert.
 
 On 27 August 2012 16:22, Jeremy Moles cubic...@gmail.com wrote:
  Hello all!
 
  I'm working on a NodeKit (that is coming along nicely, btw) for using
  the NVidia NV_path_rendering extension with OSG. This new extension has
  an interesting--and, AFAIK, hitherto unseen--rendering model.
 
  When using NV_path_rendering (which I will call NVPR), one must feed
  path coordinate data into the OpenGL driver and it will compile this
  data for you into resources the graphics context identifies by number.
  This work fairly well in OSG using the Drawable override of
  compileGLObjects(), since I am given a valid and active graphics context
  which I can use to build the renderable objects.
 
  (As a side node, for the uninitiated, a path in this context is a
  N-order series of 2D coordinates that you use to draw vectors graphics;
  for example, fonts. NVPR is an extension that uses your Cuda cores to
  drastically speed this process up and create incredibly fast and
  high-quality 2D graphics.)
 
  I mentioned earlier that compiling these objects and making them
  available to OSG (even as displayLists) is straightforward. HOWEVER,
  there is an issue with regards to properly informing OSG of the bounding
  boxes of these objects, a kind of chicken-and-egg problem. :)
 
  Up until now, Drawable objects in OSG have had some kind of 3D geometric
  data associated with them. This lets the object calculate the bounding
  box on the CPU as the object is created, and inform the scenegraph
  almost immediately what to expect with regards to its bounds. In NVPR,
  we need the GPU to compute these bounds, but it cannot do so until AFTER
  it has compiled the objects internally. This means it needs a valid
  graphics context an should ideally do so towards the end of the
  compileGLObjects method. As before, this is straightforward to execute,
  but the order of operations here makes things tricky with OSG.
 
  Consider the following:
 
  osg::Geode*g = new osg::Geode();
  osgNVPR::Path* p = new osg::PathCommands();
 
  p-doStuff();
 
  g-addDrawable(p);
  // DOH! OSG wants to do bounding calculations here, but we
  // haven't yet compiled or calculated the path internally
  // until compileGLObjects is called!
 
  I've come up with some workarounds, such as calling:
 
  viewer.realize();
  viewer.frame();
 
  ...and then manually calling dirtyBound(), but these feels very wrong to
  me.
 
  I wanted to quickly as the OSG community if they had any advice on how I
  should best approach this problem. Drawble::dirtyBound() isn't a const
  method, and so can't be easily called from compileGLObjects.
 
  Perhaps there may be some way to pre-compile these paths with a valid
  rendering context shortly after creating the Viewer?
 
  At any rate, hope everyone has a great week! LABOR DAY EXTENDED WEEKEND!
 
  ___
  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


Re: [osg-users] Chicken Egg Problem: BoundingBoxes

2012-08-27 Thread Jeremy Moles
On Mon, 2012-08-27 at 17:30 +0100, Robert Osfield wrote:
 Hi Jeremy,
 
 On 27 August 2012 17:21, Jeremy Moles cubic...@gmail.com wrote:
  This isn't currently possible because of the dirtyBound() prototypes on
  Drawable and Node (they are not const). However, if this is an API
  change you'd be agreeable to, I'd be happy to submit it. :)
 
 As you have a subclass from Drawable you should be able to set the
 dirty flag directly.

You can (and in fact you have to!), but it won't set the dirty flags of
the parent Geode, so you're forced to call dirtyBound() on it as well.
This can be tough to do because you need to be sure it has already
compiled the Paths, which is why I made the initial post.

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


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


Re: [osg-users] Camera manipulator velocity and home() calculation affected after scaling nodes

2012-08-27 Thread Jeremy Moles
On Mon, 2012-08-27 at 13:54 -0400, Judson Weissert wrote:
 Hello,
 
 I was hoping someone could help me with a camera manipulator/scaling
 problem that I have been having.
 
 I have a scene graph that contains geometry representing a hydraulic
 fracture. The fracture length is of the order 1000ft, the height is of
 the order 100ft, and the width is of the order .01ft. I am trying to
 appy a width exaggeration factor to the model in order to artificially
 inflate the geometry along the width axis (in my case it is along the
 z-axis). To accomplish this, I call
 osg::PositionAttitudeTransform::setScale(osg::Vec3d(1.0, 1.0, 100.0)) on
 the PAT node that I use to orient the fracture in the model. This works
 as expected, and the fracture width is exaggerated. However, the camera
 manipulator (osgGA::TrackballManipulator) does not return to the same
 home position. The larger the scale value, the further the home position
 seems to be from the model. Also, the velocity of the camera (model
 distance / screen pixel distance) when manipulated via the mouse
 increases with the scale value. That is, dragging the mouse an inch on
 the screen results in a larger camera manipulation when the scale value
 is increased.
 
 Perhaps I am making some false assumptions regarding how the camera
 manipulators and scaling operations interact? Is the scaling operation
 messing up a bounding box calculation somewhere? I tried computing then
 drawing the bounding box of the root node, but it did not seem to change
 for either case. That is, the exaggerated fracture width does not make
 the overall volume of the scene any larger (as far as I can tell).

I've been working on a custom OrthographicCameraManipulator (and have
done FirstPersonShooter and other kinds of CameraManipulators in the
past) and I've never seen this behave OTHER than how you're describing.

Scaling the PAT will definitely affect the home position of the
osgGA::StandardManipulator, so you may end up having to do something
like:

osgGA::CameraManipulator* cm = viewer.getCameraManipulator();

cm-setHomePosition(...);

That should also set autoComputeHomePosition to false, so it'll stick.

I could, of course, be misunderstanding the question. :)

 Additional information:
 
 Lib Version: OpenSceneGraph 3.1.2 (Compiled with VS2010 on Windows 7 64-bit)
 Manipulator: osgGA::TrackballManipulator
 
 Any hints/tips would be greatly appreciated.
 
 Thank you,
 
 Judson Weissert
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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


Re: [osg-users] Camera manipulator velocity and home() calculation affected after scaling nodes

2012-08-27 Thread Jeremy Moles
On Mon, 2012-08-27 at 15:12 -0400, Judson Weissert wrote:
 On 8/27/2012 2:22 PM, Jeremy Moles wrote:
  On Mon, 2012-08-27 at 13:54 -0400, Judson Weissert wrote:
  Hello,
 
  I was hoping someone could help me with a camera manipulator/scaling
  problem that I have been having.
 
  I have a scene graph that contains geometry representing a hydraulic
  fracture. The fracture length is of the order 1000ft, the height is of
  the order 100ft, and the width is of the order .01ft. I am trying to
  appy a width exaggeration factor to the model in order to artificially
  inflate the geometry along the width axis (in my case it is along the
  z-axis). To accomplish this, I call
  osg::PositionAttitudeTransform::setScale(osg::Vec3d(1.0, 1.0, 100.0)) on
  the PAT node that I use to orient the fracture in the model. This works
  as expected, and the fracture width is exaggerated. However, the camera
  manipulator (osgGA::TrackballManipulator) does not return to the same
  home position. The larger the scale value, the further the home position
  seems to be from the model. Also, the velocity of the camera (model
  distance / screen pixel distance) when manipulated via the mouse
  increases with the scale value. That is, dragging the mouse an inch on
  the screen results in a larger camera manipulation when the scale value
  is increased.
 
  Perhaps I am making some false assumptions regarding how the camera
  manipulators and scaling operations interact? Is the scaling operation
  messing up a bounding box calculation somewhere? I tried computing then
  drawing the bounding box of the root node, but it did not seem to change
  for either case. That is, the exaggerated fracture width does not make
  the overall volume of the scene any larger (as far as I can tell).
  I've been working on a custom OrthographicCameraManipulator (and have
  done FirstPersonShooter and other kinds of CameraManipulators in the
  past) and I've never seen this behave OTHER than how you're describing.
 
  Scaling the PAT will definitely affect the home position of the
  osgGA::StandardManipulator, so you may end up having to do something
  like:
 
  osgGA::CameraManipulator* cm = viewer.getCameraManipulator();
 
  cm-setHomePosition(...);
 
  That should also set autoComputeHomePosition to false, so it'll stick.
 
  I could, of course, be misunderstanding the question. :)
 
 Thank you.
 
 After thinking about what you said, I figured I would revisit my bounding box 
 code. I must have made a mistake the first time around because this time I do 
 get a completely different bounding box for the scene when the scale changes. 
 Therefore, the code that is computing the home position thinks that it needs 
 to view a huge volume, even though most of that volume does not actually 
 contain any drawables.
 
 Therefore, I think I need to fix the bounds calculation and then I will still 
 be able to rely on the default ComputeHomePosition algorithm. So far I have 
 just relied on the default bounds() calculations.
 
 Thanks,

A Drawable can have a special ComputeBoundsCallback() (something like
that, I'm on my phone right now and can't look it up), so you could use
that as well...

 Judson
 


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


Re: [osg-users] Chicken Egg Problem: BoundingBoxes

2012-08-27 Thread Jeremy Moles
On Mon, 2012-08-27 at 21:04 +0100, Robert Osfield wrote:
 Hi Jeremy,
 
 On 27 August 2012 17:34, Jeremy Moles cubic...@gmail.com wrote:
  You can (and in fact you have to!), but it won't set the dirty flags of
  the parent Geode, so you're forced to call dirtyBound() on it as well.
  This can be tough to do because you need to be sure it has already
  compiled the Paths, which is why I made the initial post.
 
 Interesting issue...
 
 The thing to be careful about allow a const dirtyBound() is that it
 opens the door to multi-threading issues where multiple threads could
 call dirty at one time - for instance from multiple cull traversals
 all running at the same time.  There is also the problem that calling
 dirtyBound() would force a computeBound() on the next getBound() call
 which again could present a multi-threading issue where multiple
 threads could potentially be reading and writing from the data
 structures.
 
 Now... if the drawable can only be managed from a single context or
 from a single cull thread at one time then this multi-threading issue
 wouldn't be an issue, but it's a restriction that is very domain
 specific.
 
 Rather than relax the core OSG for a niche case might the better
 solution just to cast away constness from your subclass with a note
 that it should just be used on single thread cull. There might be a
 better solution down the line but for now this is route I'd prefer to
 take.

I find myself 100% in agreement and shall proceed thusly! :)

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


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


Re: [osg-users] Node Callback never called

2012-08-23 Thread Jeremy Moles
Is your method declared as const? I always forget that...
On Aug 23, 2012 8:28 AM, Vincent Bourdier vincent.bourd...@gmail.com
wrote:

 Hi,

 I don't think, there are mutiple camera, for HUD, but the graph is
 attached to the main one.

 Regards,

 Vincent.

 Le 23/08/2012 10:28, Sergey Polischuk a écrit :

 Hi

 iirc update traversals (and may be event traversals too) dont traverse
 subgraphs under nested cameras. Is it your case?

 Cheers.

 23.08.2012, 11:09, Vincent Bourdier vincent.bourd...@gmail.com:

 Hi,

 Nice idea, but there is no other callback antwhere in the code, so i
 don't think so.

 thanks,
  Vincent.

 Le 23/08/2012 08:55, Stephan Huber a écrit :

Hi,

   any chance there's another updatecallback attached to one of the
 geode's
   parents and it is missing  a traverse(node, nv) ?

   cheers,
   Stephan

   Am 23.08.12 08:42, schrieb Vincent Bourdier:

   Hi,

   I'm currently having some troubles in my code that I didn't
 understand.
   Some help would be very apreciated :

   I have a nodeCallback to animate a shader.
   I set this callback as nodeCallback on a geode that is displayed, but
   the callback operator() is never called.
   I set the same callback as CullCallback on the same geode, now it
 works.

   Maybe this is something very simple, but after a day on this issue
 I'm
   getting mad.

   Thanks for your help.

   Regards,
   Vincent.

 __**_
 osg-users mailing list
 osg-users@lists.**openscenegraph.orgosg-users@lists.openscenegraph.org
 http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
 openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


 __**_
 osg-users mailing list
 osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
 openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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


Re: [osg-users] osgWidget Missing Resources

2012-08-23 Thread Jeremy Moles
On Thu, 2012-08-23 at 14:02 +0100, Robert Osfield wrote:
 Hi Kim,
 
 On 24 July 2012 11:59, Kim Bale kcb...@googlemail.com wrote:
  Does anybody have any idea where the missing resources for the osgWidget
  examples are?
 
  I use the latest OpenSceneGraph-Data from the svn but they're not in there.
 
  I'm referring specifically to osgwidgetmessagebox.cpp and
 
  std::string buttonTheme = osgWidget/theme-8-shadow.png;
  std::string borderTheme = osgWidget/theme-8.png;
 
  I think there are others that are missing but I haven't done a thorough
  search.
 
 If they aren't in OpenSceneGraph-Data then I don't have them.  Perhaps
 Jeremy Moles might be able to help now he's back coding on the OSG
 again...

I'm going to fix these soon, hang tight. If you need immediate help,
send me something offlist or just hit me up on Googletalk.

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


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


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

2012-08-21 Thread Jeremy Moles
On Mon, 2012-08-20 at 17:55 -0400, Jean-Sébastien Guay wrote:
 Hi Jeremy, nice to see you back writing graphics code!

I finally have the time again! 

 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,

It does. Your use of the word deferred is really helpful in this, as
it was a deferred approach I was taking and was looking for some
assurance this was an acceptable approach. :)

 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] Extensions/State Update Question

2012-08-20 Thread Jeremy Moles
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


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

2012-08-20 Thread Jeremy Moles
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://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] [3rdparty] Using OSGWidgets with OSGArt

2011-10-30 Thread Jeremy Moles
On Sun, 2011-10-30 at 09:09 +0100, Stefanos Kougiou wrote:
 Hi,
 
 I am building an application using OSGARt and I recently tried to use the 
 example: osgwidgetlabel   to show some static labels on the viewer.
 
 I followed the procedure as in the example and the labels were visible on the 
 screen. The problem is that my testcube vanished as if the tracker could not 
 recognize it on the webcam stream.
 
 I found out that the camera was the problem, specifically the setup.
 
 To enable the widgets I created a window manager and added the labels. Then I 
 used the code from the function createOrthoCamera.
 
 osg::Camera* camera = new osg::Camera();
 
 camera-getOrCreateStateSet()-setMode(
 GL_LIGHTING,
 osg::StateAttribute::PROTECTED | osg::StateAttribute::OFF
 );
 
 camera-setProjectionMatrix(osg::Matrix::ortho2D(0.0, width, 0.0f, 
 height));
 camera-setReferenceFrame(osg::Transform::ABSOLUTE_RF);
 camera-setViewMatrix(osg::Matrix::identity());
 camera-setClearMask(GL_DEPTH_BUFFER_BIT);
 camera-setRenderOrder(osg::Camera::POST_RENDER);
 
 After the creation of the camera I used the standard procedure of OSGart, 
 meaning I added the tracker and the video stream.
 
 camera - addChild(arTransform.get());
 camera - addChild(videoBackground.get());
 
 I know that the camera creation in OSGart must be done through the 
 calibration object  - osgART::Calibration 
 
 so I think it is normal that the OrthoCamera Settings cannot function 
 correctly. 
 
 Is there a way to make something like this to work?Does anyone know if there 
 is any documentation on the osgWidget objects? Any help would be appreciated. 

How many total cameras are in your scene? Geometry/Geodes in osgWidget
are no different than any other part of OSG, so you just need to make
sure all of your objects expect to be viewed the same way.

I've never used osgArt, so I can't really comment more beyond that... if
the two kits are using different setups though, just try to keep them in
sync.

 Thank you for your time!
 Stefanos
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=43632#43632
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 


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


Re: [osg-users] Rendering From First Person

2011-10-12 Thread Jeremy Moles
On Sun, 2011-10-09 at 04:53 +0200, Rishabh Taneja wrote:
 Hi Jeremy,
 
 I am a newbie in osg. I am working on a project to build a virtual 
 environment.After trying a lot, I am not able to create first person 
 experience in my environment. Can you help me out in this regard.

Sure, do you have any sample code? What OS are you on? I may be able to
provide a very simple example...

 ... 
 
 Thank you!
 
 Cheers,
 Rishabh
  (ryshabtaneja@gmail)
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=43276#43276
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 


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


Re: [osg-users] Simulation Loop in osgWidget

2011-10-12 Thread Jeremy Moles
On Tue, 2011-10-11 at 04:08 +0200, dan marshal wrote:
 Very sorry!
 
 If I create a window using:
 
  osgViewer::Viewer viewer;
  osgWidget::WindowManager* wm = new osgWidget::WindowManager(
 viewer,
 WINDOW_WIDTH,
 WINDOW_HEIGHT,
 MASK_2D
 );
 ..
 .viewer.home();
 
 I get a viewer object inside a window.
 ===
 However if I change
 
 viewer.home();
 
 to
   while(!viewer.done())
   {
   viewer.frame();
   }
 
 I lose the osgWidget:WindowManager window and the viewer object now takes 
 over the entire screen.
 
 I would like to keep my window but be able to add additional code inside the 
 viewer simulation loop.
 
 How can I use the osgWidget::Window and be able to add calls to the 
 simulation loop?
 
 Thank you again,

Hmm, I'm still not sure what's going on. Can you provide me some example
code? I tried this here on my end and saw no issues... (Linux, Fedora 15
64bit)

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=43310#43310
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 


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


Re: [osg-users] osgWidget complex widgets

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

I really, really, really wish I could help the community more with this
sort of thing. I've wanted to do more osgWidget development for a long
time, but the bills must be paid. :(

And, unfortunately, my real job has absolutely nothing to do with
graphics programming, so I have very little time to work with OSG. Maybe
one day that will change, but in the interim you're always welcome to
add me on Googletalk and bug me there (cubic...@gmail.com)

Best of luck...

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


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


Re: [osg-users] Simulation Loop in osgWidget

2011-10-10 Thread Jeremy Moles
On Mon, 2011-10-10 at 17:25 +0200, dan marshal wrote:
 Hi,
 
 I am using osgWidget to run osg inside a window frame.

Can you clarify what you mean by this? osgWidget is an OSG nodekit, I'm
not entirely sure what to derive from this statement (which makes the
rest of the e-mail impossible to understand).

Thanks!

 It works fine when I use
 
 viewer.home();
 
 No problem.
 
 However, if I use:
 
   while(!viewer.done())
   {
   viewer.frame();
   }
 to get access to the simulation loop, the widget window is lost and osg is 
 again using the full screen.
 
 How can I use osgWidget and program inside the simulation loop?
 
 Thank you
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=43302#43302
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 


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


Re: [osg-users] [ANN] New OSG book on the way, and new plan of OSG recipes

2011-09-29 Thread Jeremy Moles
On Thu, 2011-09-29 at 20:48 +0800, Wang Rui wrote:
 Hi Alessandro,
 
 I'd like to list the titles of all recipes finished until now as below.
 
 Thanks for the support. :-)
 
 Wang Rui
 
 ---
 
 [Chapter 1]
 Checking  out the latest version of OSG.
 Configure Configuring CMake options.
 Building plug-ins to support common file externsions.
 Compile Compiling and package packaging OSG on different platforms.
 Compile Compiling and use using OSG on mobile devices.
 Compile Compiling and use using dynamic and static libraries.
 Generate Generating the API documentation.
 Create Creating your own project using Cmake
 
 [Chapter 2]
 Using smart and observer pointers
 Sharing and cloning objects
 Computing the world bounding box of any node
 Creating a running car
 Mirroring the scene graph
 Designing a breadth-first node visitor
 Implementing a background image node
 Making your node always face to screen
 Using draw callbacks to execute NVIDIA Cg functions
 Implementing a compass node
 
 [Chapter 3]
 Creating a polygon with borderlines
 Extruding a 2D shape to 3D
 Drawing a NURBS surface
 Drawing a dynamic clock on the screen
 Drawing a ribbon following a model
 Selecting and highlighting a model
 Selecting a triangle face of the model
 Selecting a point of the model
 Using vertex displacement mapping in shaders
 Using the draw instanced extension
 
 [Chapter 4]
 Setting up views on multiple screens
 Using slave cameras to simulate a power-wall
 Using depth partition to display huge scene
 Implementing the radar map
 Showing the top, front and side views of a model
 Manipulating the top, front and side views
 Following a moving model
 Using manipulator to follow models
 Designing a 2D camera manipulator
 Manipulating the view with joysticks
 
 [Chapter 5]
 Opening and closing the door
 Playing a movie in the 3D world
 Designing scrolling texts
 Implementing a morph geometry
 Fading in and out
 Animating a flight on fire
 Dynamically lighting within shaders
 Creating a simple 'Galaxian' game
 Building a skeleton system
 Skinning a skeleton system
 Letting the physics engine be
 
 [Chapter 6]
 Using the bump mapping technique
 Simulating the view-dependent shadow
 Implementing transparency with multiple passes
 Reading and displaying the depth buffer
 Implementing the night vision effect
 Implementing the depth-of-field effect
 Designing a skybox with the cubemap
 Creating simple water effect
 Creating a piece of cloud
 Customizing the state attribute
 Using MRT to create the G-buffer
 Completing the deferred shading algorithm
 
 [Chapter 7]
 Preparing the VPB (VirtualPlanetBuilder) tool
 Generating small terrain database
 Generating terrain database on the earth
 Working with multiple imagery and elevation data
 Patching existing terrain database with newer data
 Building NVTT support for device-independent generation
 Using SSH to implement cluster generation
 Configuring and loading terrain from the Internet
 Playing with osgEarth: another way to visualize the world
 Use osgEarth to display VPB generated database

A lot of those look really cool; quite exciting! 

You're working on Flash support in OSG? Are there licensing issues?

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


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


Re: [osg-users] Rendering From First Person

2011-09-29 Thread Jeremy Moles
On Wed, 2011-09-28 at 11:37 -0600, Paul Martz wrote:
 On 9/28/2011 9:22 AM, Jean-Sébastien Guay wrote:
  Hi Jeremy,
 
  My question is how do I render these objects? Should I treat them
  specially (for example, adding them in a post render camera) or should I
  simply position them properly to be rendered in the main frame? I'm
  looking for some gotchas from other people who have done something
  similar.
 
  I'd render them as a separate camera, simply because they're very close to 
  the 
  eye and so might affect your depth range and precision pretty drastically. 
  If 
  you render them as a separate camera, you'll then have a main camera with a 
  z 
  range starting at over 1m (probably the ground will be the closest object 
  most 
  of the time) and a post-render camera with a very small near distance but a 
  very close far distance too, so that's ideal. You can even keep automatic 
  near-far calculation on for both, and it will likely work really well. 
 
 I agree with J-S. If you use ABSOLUTE_RF and an identity view matrix, you 
 should 
 be able to draw these scene elements directly in eye space (you're looking 
 down 
 the -z axis with +y up). In OSG parlance, it's effectively a HUD.
 
 In OpenGL, the pattern looks like: push the modelview matrix, set it to 
 identity, draw, then pop. Whenever  rendering calls for this OpenGL pattern, 
 in 
 OSG you should immediately think Camera.
 -Paul

Rendering directly into the framebuffer from a 2nd camera (like a HUD,
as you said) turned out to really simplify things, but it does--of
course--change how I need to handle lighting. Since the gun never
technically moves (though it appears to because of the first camera)
I'll have to come up with a way of updating this second camera with the
proper lighting variables...

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


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


Re: [osg-users] [ANN] New OSG book on the way, and new plan of OSG recipes

2011-09-29 Thread Jeremy Moles
On Thu, 2011-09-29 at 22:39 +0800, Wang Rui wrote:
 Hi Jeremy,
 
 We have already done an initial flash integration (including osgFlash
 abstract layer and plugins) in osgXI using GameSWF (public domain).
 But the ActionScript support is poor. Another two implementations done
 by my partner are based on ScaleForm (commercial) and COM (Windows
 only).

It was ScaleForm that inspired me to start osgWidget wwaayy back as a
building block for getting that same kind of functionality in OSG. :)

BTW: It's a shame you can't add GUI stuff to your upcoming book. The
current osgWidget is just... not enough. :)

 At present I'm working on a new integration of OSG and Vektrix. The
 latter can support AS3, and the license is MIT. The result can be
 outputted to Cairo first and then to an osgCairo image object for
 rendering, so I'm also wondering if osgCairo can be merged as a plugin
 of core OSG and then the Flash support can be added without requiring
 extra dependence.

I think Robert has looked before, but he may have decided (at least back
then) not to. The code has changed a lot since then, so perhaps another
look (later, when there's more at stake) might be good. :)

 Wang Rui
 
 
 2011/9/29 Jeremy Moles jer...@emperorlinux.com:
  On Thu, 2011-09-29 at 20:48 +0800, Wang Rui wrote:
  Hi Alessandro,
 
  I'd like to list the titles of all recipes finished until now as below.
 
  Thanks for the support. :-)
 
  Wang Rui
 
  ---
 
  [Chapter 1]
  Checking  out the latest version of OSG.
  Configure Configuring CMake options.
  Building plug-ins to support common file externsions.
  Compile Compiling and package packaging OSG on different platforms.
  Compile Compiling and use using OSG on mobile devices.
  Compile Compiling and use using dynamic and static libraries.
  Generate Generating the API documentation.
  Create Creating your own project using Cmake
 
  [Chapter 2]
  Using smart and observer pointers
  Sharing and cloning objects
  Computing the world bounding box of any node
  Creating a running car
  Mirroring the scene graph
  Designing a breadth-first node visitor
  Implementing a background image node
  Making your node always face to screen
  Using draw callbacks to execute NVIDIA Cg functions
  Implementing a compass node
 
  [Chapter 3]
  Creating a polygon with borderlines
  Extruding a 2D shape to 3D
  Drawing a NURBS surface
  Drawing a dynamic clock on the screen
  Drawing a ribbon following a model
  Selecting and highlighting a model
  Selecting a triangle face of the model
  Selecting a point of the model
  Using vertex displacement mapping in shaders
  Using the draw instanced extension
 
  [Chapter 4]
  Setting up views on multiple screens
  Using slave cameras to simulate a power-wall
  Using depth partition to display huge scene
  Implementing the radar map
  Showing the top, front and side views of a model
  Manipulating the top, front and side views
  Following a moving model
  Using manipulator to follow models
  Designing a 2D camera manipulator
  Manipulating the view with joysticks
 
  [Chapter 5]
  Opening and closing the door
  Playing a movie in the 3D world
  Designing scrolling texts
  Implementing a morph geometry
  Fading in and out
  Animating a flight on fire
  Dynamically lighting within shaders
  Creating a simple 'Galaxian' game
  Building a skeleton system
  Skinning a skeleton system
  Letting the physics engine be
 
  [Chapter 6]
  Using the bump mapping technique
  Simulating the view-dependent shadow
  Implementing transparency with multiple passes
  Reading and displaying the depth buffer
  Implementing the night vision effect
  Implementing the depth-of-field effect
  Designing a skybox with the cubemap
  Creating simple water effect
  Creating a piece of cloud
  Customizing the state attribute
  Using MRT to create the G-buffer
  Completing the deferred shading algorithm
 
  [Chapter 7]
  Preparing the VPB (VirtualPlanetBuilder) tool
  Generating small terrain database
  Generating terrain database on the earth
  Working with multiple imagery and elevation data
  Patching existing terrain database with newer data
  Building NVTT support for device-independent generation
  Using SSH to implement cluster generation
  Configuring and loading terrain from the Internet
  Playing with osgEarth: another way to visualize the world
  Use osgEarth to display VPB generated database
 
  A lot of those look really cool; quite exciting!
 
  You're working on Flash support in OSG? Are there licensing issues?
 
  ___
  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

Re: [osg-users] [ANN] New OSG book on the way, and new plan of OSG recipes

2011-09-29 Thread Jeremy Moles
On Thu, 2011-09-29 at 23:02 +0800, Wang Rui wrote:
 Hi Jeremy,
 
 2011/9/29 Jeremy Moles jer...@emperorlinux.com:
 
  BTW: It's a shame you can't add GUI stuff to your upcoming book. The
  current osgWidget is just... not enough. :)
 

How long do I have then to clean things up? :)

 Oh, in fact I'm think of introducing osgWidget in the 9th or the last
 chapter. Chapter 9 'Integrating with GUI' should meet its standing.
 :-)
 
 
  I think Robert has looked before, but he may have decided (at least back
  then) not to. The code has changed a lot since then, so perhaps another
  look (later, when there's more at stake) might be good. :)
 
 
 I just found that in the ReaderWriterPDF source code there is already
 one CairoImage class. So we had better implement a specialized Cairo
 plugin for reuse in the Flash plugin if it can be merged  in future.

There is, but osgCairo adds Serializer support, premultiply, and a
number of utility functions... I honestly don't imagine Robert having an
aversion to adding it eventually, there just needs to be a powerfully
convincing reason. :)

 Wang Rui
 ___
 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] Rendering From First Person

2011-09-28 Thread Jeremy Moles
Hey guys, looking for some quick design advice before I start hacking
something that I'd end up scrapping.

I've written a pretty traditional FPS camera; game-like movement and
strafing, sprinting, mouse viewing by warping the pointer to the center
of the screen, axis inversion, etc. All the stuff you might find in a
game like Call of Duty or similar. When this is all done, I'll probably
submit the camera (its a child of osgGA::StandardManipulator) as a new
FirstPersonManipulator...

Now I'm looking to add some facilities for attaching objects to the
scene relative to the viewing eye. For example: a weapon and a mesh
representing the viewer's arms.

My question is how do I render these objects? Should I treat them
specially (for example, adding them in a post render camera) or should I
simply position them properly to be rendered in the main frame? I'm
looking for some gotchas from other people who have done something
similar.

Thanks!

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


Re: [osg-users] osgexport for blender?

2011-09-25 Thread Jeremy Moles
On Sun, 2011-09-25 at 03:23 +0200, Damyon Wiese wrote:
 Hi Jeremy,
 
 Just thought I would post to clarify the post about my exporter (This one: 
 https://code.google.com/p/blender-osgexport-25/).
 
 I originally tried to update Cedrics exporter for blender 2.5 and got some 
 way but realised that I couldn't follow it well enough to do it without 
 introducing a heap of subtle bugs. So I started fresh and wrote that new 
 exporter you found - but my intent was just to write a proof of concept that 
 Cedric could use when he came to update his exporter - I agree that having 2 
 exporters is not the way to go and that Cedric knows more than anyone about 
 osgAnimation so his exporter should be the way forward. 
 
 I let Cedric know about my exporter off list and have been giving him updates 
 on the progress so that he can pinch bits from it when he gets to updating 
 his code to support animation. The reason I didn't announce this exporter 
 anywhere (but google found it obviously) is that I don't want to create this 
 confusion. 
 
 That said - until Cedric has finished his updates if someone uses my exporter 
 and finds a bug, post it in the google code project and I'll be happy to look 
 at it.
 
 Regards, Damyon

Ah, very cool. I tried to do the adaptation myself a few nights back,
but ran into the same issue you did: the larger, original exporter has
become (and perhaps necessarily so) quite large.

At least you're writing code though, not like me sitting on the
sidelines. :)

 ... 
 
 Thank you!
 
 Cheers,
 Damyon
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=42994#42994
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 


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


Re: [osg-users] osgexport for blender?

2011-09-23 Thread Jeremy Moles
On Fri, 2011-09-23 at 16:38 +0200, Alberto Luaces wrote:
 Benjamin Gehmlich writes:
 
  Hi Alberto,
  thanks for your answer, but there is a Problem with blender.
 
 
  When I want to add  the osgExport file (Install Add-On), there happens 
  nothing.
 
  What I have done
  1.) put the osg folder in blender-2.59/2.59/scripts/addons
  2.) the osgExport.py in blender-2.59
  3.) started Blender - User Preferences - Install Add-On
  4.) then chose osgExport.py
 
  By the other versions I used, after this I saw an entry.
 
  Is there a mistake?
 
  The other versions worked good for normaly exports, but when I chose 
  Armatur by the mesh as parent it did not export.
  Therefore I used the Modifier Armatur and i could export as osg but the 
  mesh was not correct.
 
 Benjamin,
 
 I don't fully understand how you are installing the add-on, but you have
 to take into consideration that the plugin doesn't only need
 osgExport.py, but the `osg' directory as well. Also, start Blender from
 the command line in order to check if the script is not found by your
 Python installation.

The state of the Blender export(s) requires some explanation...

Some history: Alberto wrote the first osgexport.py. A few years later,
Cedric and myself came along and improved (?) it, in a very general
sense. Another year later, Cedric wrote animtk, which eventually became
osgAnimation, and added support for that as well into the exporter.

Then, along came Blender 2.5. It drastically changed the way data is
represented and enumerated in Python internally. Cedric adapted the Mesh
exports easily enough, but the Animation exporting remains
non-functional. You can find all of this code here (git):

https://github.com/cedricpinson/osgexport.git

HOWEVER, another exporter has come into light. I'm not sure WHY this
individual chose to start over (rather than add to the existing
exporter), I do not know. The code base has become quite large however,
so perhaps that is the reason. There are also comments in the source to
the main exporter that he actually did work on it at some point. His
code DOES support animation export, but it isn't as robust as the
original in other ways. You can find that code here (git):

https://code.google.com/p/blender-osgexport-25/

To be completely honest, the state of all of this is a total mess. We
now have 2 exporters, each possessing features the other lacks, and
neither of which are (anymore) particularly clean or usable code bases.

I've talked with Cedric about the future of the original exporter, and
it certainly hasn't been forgotten, but he is an extremely, EXTREMELY
busy person and it may be a while before anything happens.

I also tried adapting the code from Wiese's exporter myself, but I can't
follow either of the exporters anymore, so no luck there...


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


Re: [osg-users] osgexport for blender?

2011-09-23 Thread Jeremy Moles
On Fri, 2011-09-23 at 17:36 +0200, Alberto Luaces wrote:
 Jeremy Moles writes:
 
  Some history: Alberto wrote the first osgexport.py.
 
 Hi Jeremy,
 
 just a clarification: I didn't wrote anything :) As far as I know, the
 original osgexport.py script belongs to Rubén López.

CRAP, you're right. Sorry. It was your thread I was responding to and
somehow I transposed that. It WAS Ruben, sorry. :)


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


Re: [osg-users] osgPango text always black (even the examples)

2011-09-19 Thread Jeremy Moles
On Sat, 2011-09-17 at 01:46 +0200, Trystan Larey-Williams wrote:
 Hi all,
 
 I've used osgPango successfully in the past on a different system, but am 
 facing a strange problem now. All text renders black including in all the 
 out-of-box examples (osgpangoanimation, etc), regardless of what the color is 
 set to in the markup. Anyone else run into this? My system/version info is 
 below.
 
 Fedora 15 / Gnome3 with proprietary nvidia drivers (280.13)
 osg version: 3.0.0
 osgPango and osgCairo 1.0.0 tag versions
 pango 1.28.4
 cairo 1.10.2
 
 I've tried updating to the latest versions of osgPango/Cairo as well, no 
 difference.
 
 Thank you!

You are encountering a driver bug. :(

You'll need the very latest OSG (with Robert's patch from last week to
change the variable naming from foo[0] to foo when appropriate).

 Cheers,
 Trystan
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=42841#42841
 
 
 
 
 
 ___
 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] Motion Blur (or What is Post Processing?)

2011-09-19 Thread Jeremy Moles
Hello all. I spent the weekend relaxing (the first in many), and had the
chance to play a few video games I've been getting behind on. It wasn't
long, however, before I saw something I wanted to implement myself,
which led me to this post. :)

In a large number of FPS/3PS shooters these days there is this concept
of a sprint; i.e., the character can--usually for a short period of
time--double or triple their movement speed. The unique aspect, however,
is that in many modern games (especially those using the Unreal engine),
they apply a very visually pleasing motion blur to the scene as well.

I began researching this, and found an article in a book called Game
Engine Gems 1 which describes this effect by creating pre and post
processing shaders, the first of which creates an acceleration buffer
and the second of which applies the blur to the frame buffer using this
data. If I'm not mistaken (though I don't fully understand the algorithm
yet) it will even blur objects in the viewers peripheral more than those
directly in front. Killer stuff.

I can't help but wonder how to best do something like this in OSG. :)

I've never used osgPPU, but I know at its core it simplifies the process
of using post processing. In a general sense though, when an article
refers to some of post processing shader on the normal frame buffer,
how does one go about implementing this in OSG? Do I create a
screen-aligned quad and set the shader to run on it in a POST_RENDER
camera?

How would you guys approach a problem like this? (Note: this question is
purely academic; it's just the latest thing bouncing around in my brain
as I try and fall asleep... :))


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


Re: [osg-users] Motion Blur (or What is Post Processing?)

2011-09-19 Thread Jeremy Moles
On Mon, 2011-09-19 at 12:52 -0600, Paul Martz wrote:
 On 9/19/2011 11:16 AM, Jeremy Moles wrote:
  I can't help but wonder how to best do something like this in OSG. :)
 
 The general solution -- OSG or whatever -- is to render your scene into one 
 or 
 more textures. Then draw a fullscreen quad to display the final image, but 
 use a 
 shader that uses your texture(s) as input to achieve the desired rendering 
 effect. Depending on the effect or effects you want, you might need to draw 
 multiple fullscreen quads with multiple different shaders, often using the 
 rendered output of the previous quad as an input texture to the next. With a 
 post-render pipeline such as this, you can create several visual effects, 
 including depth of field, motion (or other) blur, glow, heat distortion, 
 deferred lighting application, etc etc.
 -Paul

Thanks Paul--I was certainly aware of this in the general sense, but
sought some confirmation. :)

What you've described is essentially what osgPPU does (or can do), yes?

And as far as performance is concerned: how often is this rendering
paradigm used in high-fps applications? Often articles simply state
post-process the default frame buffer which leads me to believe there
are (possibly lesser) alternatives? Even so, how would subsequent
shaders have access to the former color if it wasn't stored in a texture
somewhere, so really, RTT seems to be the ONLY way (which is what
prompted this message).

Thanks for the info...

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


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


Re: [osg-users] NVidia 275-series Driver Bug

2011-09-15 Thread Jeremy Moles
On Thu, 2011-09-15 at 12:00 +0100, Robert Osfield wrote:
 Hi All,
 
 I'm note yet clear on exactly where the problems are stemming form
 with the NVidia 275+ drivers but with the assumption that the
 glGetActiveUniform is appending a [..] and the the matching
 glGetUniformLocation can handle the name without the [..] appended
 I've written some code to do the trimming off of the [..].  I've
 tested this with an artificially append [0] and it works fine, but
 haven't yet tested against the problem drivers.  My code looks like:
 
 _extensions-glGetActiveUniform( _glProgramHandle,
 i, maxLen, 0, size, type, name );
 
 int pos = strlen(name);
 if (pos0  name[pos-1]==']')
 {
 // need to trim [..] from end of name as some drivers
 append this causing problems with look up.
 --pos;
 while(pos0  name[pos]!='[') { --pos; }
 name[pos] = 0;
 }
 
 GLint loc = _extensions-glGetUniformLocation(
 _glProgramHandle, name );
 
 I have also attached the modified Program.cpp.  Could users that have
 seen the driver issue test out this proposed version of Program.cpp?
 If things work fine I'll check it into svn/trunk.

This continues to resolve the problem for me on 280+, so I must assume
it also works on 275 (the issue existed on both).

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


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


Re: [osg-users] Color grid overlay question/help

2011-09-13 Thread Jeremy Moles
On Tue, 2011-09-13 at 15:35 +0200, Kevin DeMott wrote:
 So I'm pretty close to getting this working using the osghud example code. 
 
 The problem I'm having now is that color grid on the left side of the screen 
 is not visible at the start of the application. I traced this problem down to 
 the fact that during creation the window size is larger than what the initial 
 displayed window size is. So if I manually make the window larger then the 
 color grid is visible.
 
 I fixed this problem by adding my own ResizedCallback to the GraphicsContext 
 the hud camera is using. The ResizedCallback then updates the 
 ProjectionMatrix to the dimensions of the new window size. This seems to work 
 fine for anything that is aligned with the left side of the screen. I'm now 
 working on adding another object to the hud in the upper right hand corner of 
 the screen.
 
 To do this I create the my object and then apply a PositionAttitudeTransform 
 matrix to the root node of my new object. The positional vector is based on: 
 x = width of window minus width of new object, y = height of window minus 
 height of new object.
 
 The result is that initially the object is not viewable until I manually 
 resize the window with the mouse to make the viewing area larger. I'm 
 thinking that I'm running into pretty much the same problem I had before I 
 added the ResizedCallback, which is that the window size at creation time is 
 larger than that at display time. So I'm basically placing the image beyond 
 the viewable area initially.
 
 It seems I could solve this problem by updating the PositionAttitudeTransform 
 matrix in my ResizedCallback to take into account the new window width and 
 height. However, that seems like it is going to get really tedious as more 
 and more things are added to the hud and is not the correct approach I should 
 be using.
 
 Can anyone recommend any alternative approaches to this problem? 

Is the source to this application available?

 Thanks
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=42692#42692
 
 
 
 
 
 ___
 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] Google+

2011-09-13 Thread Jeremy Moles
Who needs an invite? :) I've got 150...

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


Re: [osg-users] Skipping nodes in serialization

2011-09-06 Thread Jeremy Moles
On Sat, 2011-09-03 at 13:01 +0200, Joel Graff wrote:
 Hi,
 
 I have a graph that I serialize with a simple call to osgDB::writeNodeFile(), 
 but it contains a node that is auto-generated when the application starts.  
 Is there a way to exclude that node from serialization?  I'm familiar with 
 the setNodeMask() / setTraversalMask() mechanism used in visitor classes, but 
 wasn't finding something similiar for serialization - nothing jumped out at 
 me in the ReaderWriter docs, anyway.

It is really mind-boggling-ly easy to write a serializer wrapper. Here,
I'll show you (this file is generally called LibraryWrapper.cpp):

--

#include osgDB/Registry
#include osgDB/ObjectWrapper

extern C void wrapper_serializer_library_myLibrary(void) {
}

REGISTER_OBJECT_WRAPPER(
myLibrary_Object,
new myLibrary::Object(),
myLibrary::Object,
osg::Object osg::MatrixTransform myLibrary::Object
) {
}

-

As long as your object can be built after construction this will be a
suitable workaround. If you want to actually serialize members, well,
that's also incredibly easy (depending on what type of data they are).

You can find some examples here:

http://code.google.com/p/osgpango/source/browse/#svn%2Ftrunk%2Fsrc%
2Fserializers

...or all throughout the code in $OSG/src/osgWrappers/serializers/

 ... 
 
 Thank you!
 
 Cheers,
 Joel
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=42403#42403
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 


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


Re: [osg-users] Unable to load osgdb_tiff plugin on CentOS 5.6

2011-09-02 Thread Jeremy Moles
On Fri, 2011-09-02 at 13:17 -0400, Cary, Karl A. wrote:
 I developed something that uses tiffs as textures and developed it in
 CentoS 5.5 and everything works just fine. The installation of OSG on
 the system was actually built on a CentOS 5.6 machine and then rpm’d
 and installed on the 5.5 system. When I try to run the code on 5.6, I
 get that it cannot load the tiff plugin. We are able to use other
 plugins just fine though. Does anyone have any idea where to begin
 looking? I am extremely rushed as this has to be working today and I
 head out tonight for a week long vacation.

You're probably just missing the libtiff RPM on the new machine, or some
similar library.

Run your program like:

OSG_NOTIFY_LEVEL=DEBUG ./my_binary

...and see if you can track it down.

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


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


Re: [osg-users] iOS: wireframe

2011-09-02 Thread Jeremy Moles
On Fri, 2011-09-02 at 18:11 +0200, Alessandro Terenzi wrote:
 Ok and thanks for your help.

I think I might finish my own personal solid+wireframe GLSL example here
in a few minutes. Would this be of use to you? (It is derived from this
example:

http://www2.imm.dtu.dk/~jab/Wireframe/



 Cheers.
 Alessandro
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=42387#42387
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 


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


Re: [osg-users] I made the libRocket GUI library usable with OSG

2011-08-28 Thread Jeremy Moles
On Sat, 2011-08-27 at 07:09 +0200, Martin Scheffler wrote:
 Hi Jeremy,
 
 I hope I haven't discouraged you from continuing development on osgWidget! A 
 native osg gui would have a lot of advantages over an external library. The 
 main reason I did not consider osg widget was the lack of documentation, so 
 maybe you can invest some time in that...

It won't at all. I just need to find the time, or at least the funding
so I can MAKE time. :)

The next version will be much better, as I've learned exponentially
since then...

 About the missing CMake variables: Are you using the advanced mode in 
 cmake-gui? The libRocket variables are marked as advanced, I have not yet hd 
 time to find out how to mark them as non-advanced.

Whoops. Got it...

 Cheers,
 Martin
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=42272#42272
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 


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


Re: [osg-users] I made the libRocket GUI library usable with OSG

2011-08-26 Thread Jeremy Moles
On Fri, 2011-08-26 at 06:38 +0200, Martin Scheffler wrote:
 Hi all,
 
 On a long train ride yesterday I had the chance to work on my osg 
 implementation of a libRocket interface. You can download the code from the 
 attachment.
 
 
 
 libRocket is a nice little GUI library that seems to be well thought through 
 and cleanly coded. There is an html-like format for writing GUIs. I have not 
 yet fully explored the library, but now that I can use it in OSG I surely 
 will.
 
 What it can do at this point:
 * Create fullscreen GUIs
 * Create in-scene GUIs
 * Mouse and keyboard events are transformed to GUI coordinates and forwarded 
 to libRocket system
 
 That's all, and I think that is all that is needed.
 I don't think I will wrap any other libRocket functionality as it is all 
 accessible.
 
 The included example shows two GUIs. One is full screen, the other is 
 in-scene and can be rotated with the default osgViewer mouse manipulator.
 
 If anyone is interested in this I can put it on source control somewhere. 
 Please give me feedback on what is missing or what can be improved!

Having made osgWidget all those years ago it really makes me sad when I
see stuff like this, but the bottom line is osgWidget simply isn't good
enough. I've wanted to, for a long, long, time, go back and make it
better. :)

HOWEVER, having said that, this is actually a great little library. Not
bad at all, the design seems very solid! I think if you figure out the
issues with cleaning up, it could become quite popular in the OSG
community.

BTW: I can't actually get it to compile yet (though I can run the Rocket
examples just fine); CMake won't find/define LIBROCKET_* variables...

 Cheers,
 Martin
 [/img]
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=42250#42250
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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


Re: [osg-users] ANN: osgNVPR (NVidia Path Rendering)

2011-08-25 Thread Jeremy Moles
On Wed, 2011-08-24 at 06:43 +0200, Mark Kilgard wrote:
 Jeremy,
 
 Very cool to see this OpenSceneGraph support for NV_path_rendering.

And even cooler to get an @nvidia.com response. :)

 I hope you'll explore the ability to mix 3D and path rendering within a 
 depth-buffered perspective scene as discussed in the Mixing Path Rendering 
 and 3D whitepaper.
 
 Any CUDA-capable NVIDIA GPU under Windows or Linux can use NV_path_rendering 
 with Release 275 drivers or later.
 
 A few suggestions for your osgNVPR::Path object:
 
 *  Consider having the _colors be a path paint object.  Solid color (what 
 you have now) is one paint style, but linear gradient color, radial gradient 
 color, and image paint are others common to path rendering standards.  (See 
 the nvpr_svg SDK example to see how simple the shaders are for linear and 
 radial gradients.)
 
 *  Eventually you could have paint shaders where you can use arbitrary 
 assembly, Cg, or GLSL shaders to paint your paths during the cover operation. 
  Environment mapped or bump mapped paths are possibilities.
 
 *  Have separate fill and stroke paint.  Sometimes you want the stroking to 
 happen before the filling (such as for matting text rendering) but usually 
 the stroking is an outline around the path drawn over the filled version of 
 the path.  Have an option for either.  null paint would skip the filling or 
 stroking.
 
 *  Have methods to set stroking styles (end caps, join style, dash pattern, 
 dash caps, and stroke width).
 
 *  Be able to initialize a path from an actual string of text and a font name 
 (and font style).  This way someone can create a osgNVPR::Path for Hello 
 world in Arial or whatever.
 
 *  Have a mode to say whether mixing with depth testing should be done.
 
 *  Provide an option to cache the drawing commands for a path object in a 
 display list.  All the NV_path_rendering commands are display-listable.  
 Because the NVIDIA OpenGL driver is dual-core enabled, this allows you to 
 draw a path with a single glCallList command relayed over to the driver 
 thread on another core.  This gives your app thread more CPU cycles.
 
 *  You should be able to support picking support with the 
 glIsPointInFillPathNV and glIsPointInStrokePathNV queries.  Since you have 
 the bounding box queried already, it makes sense to test against the bounding 
 box first before doing the (more expensive) glIsPointInFillPathNV query.
 
 I look forward to seeing how this develops.

Really good suggestions, all stuff I'd like to do...

Unfortunately, I did most of what is currently in osgNVPR over a weekend
in a attempt to see if there was any interest in funding for such a
NodeKit in OSG. As of yet, there has been none, so development will be
on hold (for now).

 - Mark
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=42207#42207
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 


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


Re: [osg-users] Custom Vertex Attributes Binding

2011-08-23 Thread Jeremy Moles
On Tue, 2011-08-23 at 22:27 +0200, Tony Horrobin wrote:
 Hi Jeremy,
 
 The glsl attachments have been squashed - could you attach them as .txt, 
 please?
 
 I believe you have to bind shader vertex attributes as PER_VERTEX as opposed 
 to colours and normals which can be PER_PRIMITIVE.
 Then copy the line that calls push_back() on gridCoordinates so you have 4 
 calls and it should work.
 
 I had to add:
 setVertexArray(gridPositions);

You shouldn't have to call this at all. Something is still wrong if you
need to. :( Drats...

 to get anything at all on the screen ( otherwise there are no primitives ).

 Cheers,
 
 -Tony
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=42202#42202
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 


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


Re: [osg-users] Custom Vertex Attributes Binding

2011-08-23 Thread Jeremy Moles
On Tue, 2011-08-23 at 22:27 +0200, Tony Horrobin wrote:
 Hi Jeremy,
 
 The glsl attachments have been squashed - could you attach them as .txt, 
 please?
 
 I believe you have to bind shader vertex attributes as PER_VERTEX as opposed 
 to colours and normals which can be PER_PRIMITIVE.
 Then copy the line that calls push_back() on gridCoordinates so you have 4 
 calls and it should work.
 
 I had to add:
 setVertexArray(gridPositions);
 
 to get anything at all on the screen ( otherwise there are no primitives ).

OH WAIT, if you weren't using the shaders, then on wonder. :) So,
scratch my first response.

As far as your binding speculation is concerned: you are probably right.
I was just hoping I could avoid some repetitive memory use for the
heightfields this way.

 Cheers,
 
 -Tony
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=42202#42202
 
 
 
 
 
 ___
 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] Custom Vertex Attributes Binding

2011-08-22 Thread Jeremy Moles
Hello everyone.

I am using custom vertex attributes but running into a strange issue. I
do not seem to be able to use:

BIND_PER_PRIMITIVE

..when using custom vertex attributes. Is this a known limitation, or is
it likely a bug/me doing something wrong? I have attached a simple
example of this failure; if you uncomment GridCoordinates, nothing is
rendered at all (nor do I receive any information via OSG_NOTIFY).

If you keep this commented out, the grid renders.

Curious...
#include osg/Geometry
#include osg/Geode
#include osg/PrimitiveSet
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers

class Grid: public osg::Geometry {
public:
	enum {
		GRID_POSITION   = 6,
		GRID_COORDINATE = 7
	};

	Grid(const osg::Vec2s size, const osg::Vec2 gridSize = osg::Vec2(1.0f, 1.0f)):
	_size (size),
	_gridSize (gridSize) {
		setUseDisplayList(false);
	}

	bool allocate() {
		osg::Program* program = new osg::Program();
		osg::Shader*  vert= osg::Shader::readShaderFile(osg::Shader::VERTEX, vert.glsl);
		osg::Shader*  frag= osg::Shader::readShaderFile(osg::Shader::FRAGMENT, frag.glsl);
		// osg::Uniform* texture = new osg::Uniform(osg::Uniform::SAMPLER_2D, Texture);
		
		program-addShader(vert);
		program-addShader(frag);
		program-addBindAttribLocation(GridPosition, GRID_POSITION);
		program-addBindAttribLocation(GridCoordinate, GRID_COORDINATE);

		osg::Vec4Array* gridPositions   = new osg::Vec4Array();
		osg::Vec2Array* gridCoordinates = new osg::Vec2Array();

		for(short x = 0; x  _size.x(); x++) {
			for(short y = 0; y  _size.y(); y++) {
osg::Vec4 bl(x, y, 0.0f, 0.0f);
osg::Vec4 br(x + _gridSize.x(), y, 0.0f, 1.0f);
osg::Vec4 ur(x + _gridSize.x(), y + _gridSize.y(), 0.0f, 2.0f);
osg::Vec4 ul(x, y + _gridSize.y(), 0.0f, 3.0f);

gridPositions-push_back(bl);
gridPositions-push_back(br);
gridPositions-push_back(ur);
gridPositions-push_back(ul);

gridCoordinates-push_back(osg::Vec2(x, y));
			}
		}

		// GridPosition
		setVertexAttribArray(GRID_POSITION, gridPositions);
		setVertexAttribBinding(GRID_POSITION, osg::Geometry::BIND_PER_VERTEX);

		/*
		// GridCoordinates
		setVertexAttribArray(GRID_COORDINATE, gridCoordinates);
		setVertexAttribBinding(GRID_COORDINATE, osg::Geometry::BIND_PER_PRIMITIVE);
		u*/

		// Finish seting up the Geometry...
		addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::QUADS, 0, _size.x() * _size.y() * 4));

		// texture-set(0);

		osg::StateSet* state = getOrCreateStateSet();

		state-setAttributeAndModes(program);
		// state-addUniform(texture);

		return true;
	}

	virtual osg::BoundingBox computeBound() const {
		return osg::BoundingBox(
			osg::Vec3(0.0f, 0.0f, 0.0f),
			osg::Vec3(_size.x() * _gridSize.x(), _size.y() * _gridSize.y(), 0.0f)
		);
	}

private:
	osg::Vec2s _size;
	osg::Vec2  _gridSize;
};

int main(int argc, char** argv) {
	osgViewer::Viewer viewer;

	Grid* grid = new Grid(osg::Vec2s(10, 10));

	grid-allocate();

	osg::Geode* geode = new osg::Geode();

	geode-addDrawable(grid);

	viewer.setSceneData(geode);
	viewer.addEventHandler(new osgViewer::StatsHandler());

	return viewer.run();
}

varying float color;

void main() {
gl_FragColor = vec4(color, color, color, 1.0);
}

in vec4 GridPosition;
in vec2 GridCoordinate;

varying float color;

void main() {
color = GridPosition.w / 3.0;

gl_Position = gl_ModelViewProjectionMatrix * vec4(GridPosition.xyz, 
1.0);
}

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


Re: [osg-users] osgWidget::Label::setLabel() does not update the size

2011-08-19 Thread Jeremy Moles
On Fri, 2011-08-19 at 15:31 +0200, Daniel Cámpora wrote:
 Hi,
 
 I had the same problem and ended up overriding the _calculateSize method as 
 you are doing.
 
 However, I don't think this is an error of the bounding box. What happens 
 internally is that the text has a width and height according to the first 
 text that we fit in, and it's only updated IF the text occupies more space, 
 shall it be width or heigth.
 
 On the other hand, I think it's not a good approach to remove completely the 
 if statement, because that would imply the size of the box is always going to 
 be that one of the text's. Eg. suppose you want a bigger container with a 
 background color specified by user's width and height.
 
 I went for two booleans, _userWidth and _userHeight which are set 
 whenever the user wants to define a custom width or height (in the setters 
 and adders). With this, the _calculateSize looks like this:
 
 
 Code:
 void EnhancedWidgetText::_calculateSize(const osgWidget::XYCoord size){
   if(!_userWidth || getWidth()  size.x())
   inherited::setWidth(size.x());
 
   if(!_userHeight || getHeight()  size.y())
   inherited::setHeight(size.y());
 }
 
 
 
 If someone is interested I can provide the implementation.
 
 Btw, among other things, you'll find out the padding is not supported in 
 canvas widgets. An addition could be added in this direction, maybe.

Honoring Widget sizing hints is the job of each Window (and could mean
different things). Canvas is truly free-form, so it doesn't even look at
any of that. :)

 Cheers,
 
 Daniel
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=42132#42132
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 


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


Re: [osg-users] osgWidget Callbacks

2011-08-19 Thread Jeremy Moles
On Fri, 2011-08-19 at 16:36 +0200, Daniel Cámpora wrote:
 Hello :),
 
 I'm working my way on osgWidgets, and I have come into using callbacks for 
 them.
 
 The way for adding callbacks on them is by means of the method 
 osgWidget::EventInterface::addCallback, but I didn't find any way to remove 
 a callback after it's been added.
 
 After reading some code definitions, I found out callbacks are stored in a 
 std::list, and they are defined in the private scope, so therefore I have 
 virtually no way of sorting this out.
 
 Is there any workaround for this?

This is simply an oversight. Submit a patch for this and I'm certain it
will be accepted.

 Thank you!
 
 Cheers,
 Daniel
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=42135#42135
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 


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


Re: [osg-users] osg::Image Serialization

2011-08-17 Thread Jeremy Moles
On Wed, 2011-08-17 at 08:48 +0800, Wang Rui wrote:
 Hi Jeremy and Robert,
 
 In fact the osg::Image class can be derived and it is possible to
 write serializers for the subclasses. In
 osgWrappers/serializers/osg/ImageStream.cpp you will find an example
 which has no difference from other serializers. I'm not sure if this
 could work for osgCairo images, but I think a subclass that doesn't
 change osg::Image's basic functionalities can work fine with
 serializers at present.

I'm not entirely sure this is accurate; if you look at osgimagesequence
example, it lets you write the file out to disk:

osgimagesequence -o foo.osgt

...but that file isn't readable by OSG. In fact, I had no trouble ever
writing my custom Image to disk, only reading it back in.

However, the serializer backend is very complex (or rather, quite
abstracted away in macros), and so I've found it difficult to track down
where exactly to investigate...

 After reviewing the source code, I think it also possible to replace
 the readImage() and writeImage() in Input/OutputStream classes with an
 Image serializer, too. I can't remember why I use special
 reader/writer functions to handle images. Maybe it is only a
 plagiarism of old osgDB::Input/Output class' methods. :-P

Perhaps this is where I should look then. :)

 Cheers,
 
 Wang Rui
 
 
 2011/8/17 Jeremy Moles jer...@emperorlinux.com:
  Hello everyone; this is probably a question only a few people could
  possibly, answer (Robert, Wang), but here goes:
 
  I have created a derived osg::Image class (osgCairo::Image), and this
  has worked just fine for the last few years. However, I want to add
  strong serialization support for my nodekits, and I'm finding
  customizing an Images behavior in the serialization code is quite
  difficult.
 
  Images are treated as special kinds of Objects, so any custom behavior
  you might add confuses the base serializers, and there doesn't appear to
  be any way to avoid this.
 
  My question is: should the serialization backend be modified to support
  osg::Image subclasses, or should programmers be encouraged NOT to derive
  from osg::Image directly and instead create contains-a objects
  instead?
 
  ___
  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


[osg-users] osg::Image Serialization

2011-08-16 Thread Jeremy Moles
Hello everyone; this is probably a question only a few people could
possibly, answer (Robert, Wang), but here goes:

I have created a derived osg::Image class (osgCairo::Image), and this
has worked just fine for the last few years. However, I want to add
strong serialization support for my nodekits, and I'm finding
customizing an Images behavior in the serialization code is quite
difficult.

Images are treated as special kinds of Objects, so any custom behavior
you might add confuses the base serializers, and there doesn't appear to
be any way to avoid this.

My question is: should the serialization backend be modified to support
osg::Image subclasses, or should programmers be encouraged NOT to derive
from osg::Image directly and instead create contains-a objects
instead?

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


Re: [osg-users] osg::Image Serialization

2011-08-16 Thread Jeremy Moles
On Tue, 2011-08-16 at 12:42 -0400, Jeremy Moles wrote:
 Hello everyone; this is probably a question only a few people could
 possibly, answer (Robert, Wang), but here goes:
 
 I have created a derived osg::Image class (osgCairo::Image), and this
 has worked just fine for the last few years. However, I want to add
 strong serialization support for my nodekits, and I'm finding
 customizing an Images behavior in the serialization code is quite
 difficult.
 
 Images are treated as special kinds of Objects, so any custom behavior
 you might add confuses the base serializers, and there doesn't appear to
 be any way to avoid this.
 
 My question is: should the serialization backend be modified to support
 osg::Image subclasses, or should programmers be encouraged NOT to derive
 from osg::Image directly and instead create contains-a objects
 instead?

As an addendum, this may simply be a misuse on my part.

Perhaps if someone is deriving from osg::Image, that person should also
consider creating a custom image type and, thus, writing an osgPlugin
for their image type to do the various kinds of extra stuff they need to
do.

For example, in osgCairo, though I may actually be using PNG data, I
could create a .cairo file type which will force my custom loader
instead of the default loader (which will allow me to do things like
pre-multiply the alpha, which Cairo expects internally).

Just thinking out loud here. :)

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


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


Re: [osg-users] osgWidget::Label::setLabel() does not update the size

2011-08-12 Thread Jeremy Moles
On Fri, 2011-08-12 at 11:09 +0200, Yue Zijian wrote:
 [code]
 #include osgWidget/Util
 #include osgWidget/WindowManager
 #include osgWidget/Canvas
 
 const unsigned int MASK_2D = 0xF000;
 
 
 int main(int argc, char** argv) {
 osgViewer::Viewer viewer;
 
 osgWidget::WindowManager* wm = new osgWidget::WindowManager(
 viewer,
 1280.0f,
 1024.0f,
 MASK_2D,
 osgWidget::WindowManager::WM_PICK_DEBUG
 );
 
 osgWidget::Canvas* canvas = new osgWidget::Canvas(canvas);
 
 osgWidget::Label* label = new osgWidget::Label( label_test, test );
 
 label-setFontColor( 1.0f, 0.0f, 0.0f, 1.0f );
 
 canvas-addWidget( label, 0.0f, 0.0f );
 
 canvas-resize();
 
 wm-addChild(canvas);
 
 return osgWidget::createExample(viewer, wm);
 }
 [/code]
 
 the canvas bg grows taller after the window size changed.

This is probably the bug where the bounding box of the Text isn't
proper; what version of OSG are you using?

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=42017#42017
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 


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


Re: [osg-users] blender2.5 exporter

2011-08-10 Thread Jeremy Moles
On Wed, 2011-08-10 at 14:21 +0200, Cedric Pinson wrote:
 Hi,
 
 just to talk about the blender 2.5 exporter. The plugin is on github
 https://github.com/cedricpinson/osgexport
 I fixed a few things and optimized model. I setup unittest too.
 Sadly the exporter does not support animation yet. It should come in a
 near futur.

Woot! 2.5 is (IMO) the best version of Blender to date, so this is
awesome.

What are the complications with 2.5 and animation? Has the internal
animation mechanism been totally redesigned, or is it just getting at
the old data in a new Python interface?

 if you want to report bug/improve it everything is on github.
 
 Cheers,
 Cedric
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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


Re: [osg-users] Timers for OSG Application

2011-08-10 Thread Jeremy Moles
On Wed, 2011-08-10 at 12:35 +0200, Ankur Gandhi wrote:
 Dear All,
 
 I am making a scene graph in OSG and things are going great. Extensive 
 support is available in forums and tutorials of OSG. Thanks a lot for that.
 
 I have one doubt. It may not be related to OSG but may be related general 
 application development based on OSG.

 To update my scenegraph periodically, I want to use timer. I want a 
 particular function to be called every few seconds or so.
 
 In GTK, I used to use g_timeout_add() function. However I believe OSG doesn't 
 use g_main_loop() inside its render API. is it correct?

No, it doesn't.

 Can some one tell me equivalent API for g_timeout_add() for OSG based 
 application? or is there any other way to implement timer callback in OSG?

There must be at least 200 different ways to do this. :)

If it's just one Node you want updated, then create a NodeCallback
object and fetch the elapsed time from:

NodeVisitor-getFrameStamp()-getSimulationTime()

If you want to visit your entire scenegraph instead, have this Node
create a NodeVisitor and let it visit the subgraph.

You could also replace your call to viewer.run() with manual calls to
realize/frame/etc., but I still recommend the first method. :)

 Thanks in advance!
 
 Cheers,
 Ankur
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=41972#41972
 
 
 
 
 
 ___
 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] Serialization Question (Proto Constructors)

2011-08-10 Thread Jeremy Moles
This question is for anyone who has used the new serialization interface
introduced by Wang Rui in 2010 (osgWrappers/serializers).

Is it possible to pass arguments to the object's constructor? The 2nd
argument to the REGISTER_ macro lets you define the protocol for object
creation, but the arguments cannot (as far as I can tell) be
dynamic--and certainly not values from the serialization stream--right?

Please correct me if I'm wrong... :)

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


Re: [osg-users] Serialization Question (Proto Constructors)

2011-08-10 Thread Jeremy Moles
On Thu, 2011-08-11 at 08:16 +0800, Wang Rui wrote:
 Hi Jeremy,
 
 Yes. The serializers at present don't support constructor with
 arguments. It is welcome if you and anyone else could provide the
 functionality. :-)

I'll see if I can do it...

BTW: Working with the new serializer interfaces has been a breeze; it's
really great stuff! I might make a small example showing how to do it
for others to get up to speed. The 'osguserdata' examples gives some
hints, but really people will want to know how to use
{Input,Output}Stream.{write,read}Object(), what the serializer macros
do, etc.

It's been quite easy though, and I'm definitely not using it a simple
way. :)

 Wang Rui
 
 
 2011/8/11 Jeremy Moles jer...@emperorlinux.com:
  This question is for anyone who has used the new serialization interface
  introduced by Wang Rui in 2010 (osgWrappers/serializers).
 
  Is it possible to pass arguments to the object's constructor? The 2nd
  argument to the REGISTER_ macro lets you define the protocol for object
  creation, but the arguments cannot (as far as I can tell) be
  dynamic--and certainly not values from the serialization stream--right?
 
  Please correct me if I'm wrong... :)
 
  ___
  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


Re: [osg-users] Camera returns NULL viewport on Windows but not Linux

2011-08-09 Thread Jeremy Moles
On Tue, 2011-08-09 at 22:05 +0200, Paul Leopard wrote:
 I have some code I have inherited that was developed on Linux. I am trying to 
 get a Windows version of it to run but there is an inconsistency that I am 
 unable to explain. Perhaps someone here has seen this issue before ...
 
 Anyway, the problem is that on Windows (OSG v2.9.9 and v3.0.0) I get a NULL 
 viewport pointer with the following (pseudocode) call to getViewport() :
 
 Code:
 osg::ArgumentParser arguments(argc,argv);
 osgViewer::Viewer viewer(arguments);
 viewer.addEventHandler(...);
 osg::Group* root = new osg::Group;
 root-addChild( ... );
 viewer.frame();

Try viewer.realize() here instead; not sure it'll change anything, but
it's worth a shot.

 osg::Camera* camera = viewer.getCamera();
 assert(camera!=NULL); // Ok
 osg::Viewport* pViewPort = camera-getViewport();
 assert(pViewPort !=NULL); // FAILS! NULL POINTER
 
 
 
 
 On Linux the pointer is valid, on Windows it is always NULL. Am I missing 
 something here or has anyone else had this issue?
 
 
 Thanks!
 Paul
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=41955#41955
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 


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


Re: [osg-users] ANN: osgNVPR (NVidia Path Rendering)

2011-08-05 Thread Jeremy Moles
On Fri, 2011-08-05 at 10:11 -0500, Michael Weiblen wrote:
 heh, first osgVRPN, now osgNVPR  :-)
 
 That said, this is quite an interesting extension.
 
 -- mew

Hmm, perhaps osgNVPath would be better. :)

 On Thu, Aug 4, 2011 at 2:23 PM, Jeremy Moles jer...@emperorlinux.com wrote:
  NVidia recently added an extension to their 275+ series of drivers
  called GL_NV_path_rendering. This turns path (sometimes called vector
  graphics) rendering into first class drawables in OpenGL. Honestly, it's
  one of the coolest things I've seen in a while, and naturally--given my
  interest in OpenGL UIs--I began researching it and putting together a
  NodeKit for OSG.
 
  You can find it (in its infancy) here:
 
  http://osgnvpr.googlecode.com
 
  Run the example thusly:
 
 # osgnvprviewer
 # osgnvprviewer --perspective
 
  ..and notice how that no matter what the resolution, scale, or
  projection, the objects are rendered clear and crisp. There is also
  support for glyphs inside of GL_NV_path_rendering, so I will very soon
  be adding support for this style of text rendering into osgPango (and
  possible, osgText::TextNode).
 
  I've only just begun exploring this, and I'm mainly sending this e-mail
  to see if there is any professional interest in seeing this NodeKit
  mature in a timely fashion. I don't know if this is outside the
  allowable etiquette of the lists, but in full disclosure I'm looking to
  fill some free time by seeking funding for development of by those who
  would not only use these features but could benefit from being able to
  influence their development and pace! If this is inappropriate for the
  lists, just let me know and I'll be sure and keep my peddling to a
  minimum from here on out. :)
 
  At any rate, I'll continue to work on osgNVPR regardless, alongside
  devleopment of osgCairo/Pango/Widget and the recent TextNode submission.
  (Can you see a pattern here? All OSG interface development tools...)
 
  Some notes:
 
 - NV_path_rendering introduces a new kind of rendering style for 
  its
  path objects. This doesn't map 1:1 to any existing usage of
  osg::Drawable, though I am able to hijack the compileGLObjects()
  method to get what I need. :)
 
 - BoundingBoxes are calculated with an extension call, but in order 
  to
  use the extension I need a contextID (provided via either a State object
  or RenderInfo object). Unfortunately, these are difficult to get to at
  times, so CameraManipulators cannot properly determine a home position
  unless the Path has been compiled.
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
  http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 
 


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


Re: [osg-users] ANN: osgNVPR (NVidia Path Rendering)

2011-08-05 Thread Jeremy Moles
On Fri, 2011-08-05 at 17:15 +0200, Cedric Pinson wrote:
 Hi,
 The alternative would be distance map. It works really well.

Yeah. I recently added a DistanceFieldFont object to osgPango, though it
still needs some tweaking--particularly with regards to when the glyph
is resized smaller than the texture; larger always looks great. :)

 Cedric
 
 On Fri, 2011-08-05 at 08:48 -0400, Glenn Waldron wrote:
  I was just thinking the same thing. :) Labels too.
  
  Glenn Waldron / Pelican Mapping / @glennwaldron
  
  
  On Fri, Aug 5, 2011 at 2:56 AM, J.P. Delport jpdelp...@csir.co.za
  wrote:
  Hi Jeremy,
  
  if this could be combined with osgEarth it would be very cool
  for overlays.
  
  rgds
  jp
  
  
  
  On 04/08/2011 21:23, Jeremy Moles wrote:
  NVidia recently added an extension to their 275+
  series of drivers
  called GL_NV_path_rendering. This turns path
  (sometimes called vector
  graphics) rendering into first class drawables in
  OpenGL. Honestly, it's
  one of the coolest things I've seen in a while, and
  naturally--given my
  interest in OpenGL UIs--I began researching it and
  putting together a
  NodeKit for OSG.
  
  You can find it (in its infancy) here:
  
  http://osgnvpr.googlecode.com
  
  Run the example thusly:
  
 # osgnvprviewer
 # osgnvprviewer --perspective
  
  ..and notice how that no matter what the resolution,
  scale, or
  projection, the objects are rendered clear and crisp.
  There is also
  support for glyphs inside of GL_NV_path_rendering, so
  I will very soon
  be adding support for this style of text rendering
  into osgPango (and
  possible, osgText::TextNode).
  
  I've only just begun exploring this, and I'm mainly
  sending this e-mail
  to see if there is any professional interest in seeing
  this NodeKit
  mature in a timely fashion. I don't know if this is
  outside the
  allowable etiquette of the lists, but in full
  disclosure I'm looking to
  fill some free time by seeking funding for development
  of by those who
  would not only use these features but could benefit
  from being able to
  influence their development and pace! If this is
  inappropriate for the
  lists, just let me know and I'll be sure and keep my
  peddling to a
  minimum from here on out. :)
  
  At any rate, I'll continue to work on osgNVPR
  regardless, alongside
  devleopment of osgCairo/Pango/Widget and the recent
  TextNode submission.
  (Can you see a pattern here? All OSG interface
  development tools...)
  
  Some notes:
  
 - NV_path_rendering introduces a new kind of
  rendering style for its
  path objects. This doesn't map 1:1 to any existing
  usage of
  osg::Drawable, though I am able to hijack the
  compileGLObjects()
  method to get what I need. :)
  
 - BoundingBoxes are calculated with an
  extension call, but in order to
  use the extension I need a contextID (provided via
  either a State object
  or RenderInfo object). Unfortunately, these are
  difficult to get to at
  times, so CameraManipulators cannot properly determine
  a home position
  unless the Path has been compiled.
  
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
  
  http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
  
  
  
  -- 
  This message is subject to the CSIR's copyright terms and
  conditions, e-mail legal notice, and implemented Open Document
  Format (ODF) standard. The full disclaimer details can be
  found at http://www.csir.co.za/disclaimer.html

[osg-users] ANN: osgNVPR (NVidia Path Rendering)

2011-08-04 Thread Jeremy Moles
NVidia recently added an extension to their 275+ series of drivers
called GL_NV_path_rendering. This turns path (sometimes called vector
graphics) rendering into first class drawables in OpenGL. Honestly, it's
one of the coolest things I've seen in a while, and naturally--given my
interest in OpenGL UIs--I began researching it and putting together a
NodeKit for OSG.

You can find it (in its infancy) here:

http://osgnvpr.googlecode.com

Run the example thusly:

# osgnvprviewer
# osgnvprviewer --perspective

..and notice how that no matter what the resolution, scale, or
projection, the objects are rendered clear and crisp. There is also
support for glyphs inside of GL_NV_path_rendering, so I will very soon
be adding support for this style of text rendering into osgPango (and
possible, osgText::TextNode).

I've only just begun exploring this, and I'm mainly sending this e-mail
to see if there is any professional interest in seeing this NodeKit
mature in a timely fashion. I don't know if this is outside the
allowable etiquette of the lists, but in full disclosure I'm looking to
fill some free time by seeking funding for development of by those who
would not only use these features but could benefit from being able to
influence their development and pace! If this is inappropriate for the
lists, just let me know and I'll be sure and keep my peddling to a
minimum from here on out. :)

At any rate, I'll continue to work on osgNVPR regardless, alongside
devleopment of osgCairo/Pango/Widget and the recent TextNode submission.
(Can you see a pattern here? All OSG interface development tools...)

Some notes:

- NV_path_rendering introduces a new kind of rendering style for its
path objects. This doesn't map 1:1 to any existing usage of
osg::Drawable, though I am able to hijack the compileGLObjects()
method to get what I need. :)

- BoundingBoxes are calculated with an extension call, but in order to
use the extension I need a contextID (provided via either a State object
or RenderInfo object). Unfortunately, these are difficult to get to at
times, so CameraManipulators cannot properly determine a home position
unless the Path has been compiled.

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


[osg-users] Custom Drawables

2011-08-02 Thread Jeremy Moles
Hello all! I am writing a custom Drawable that uses some new OpenGL
extension functions. I have an Extensions class (essentially copied from
the one defined in PixelBufferObject) that does the standard binding of
extension name string to function pointer.

However, these are members of the Extensions singleton, and to use them
in my drawImplementation, I am fetching the instance of Extensions and
using them thusly:

Extenions* ext = getExstensions();

ext-glCustomFunction(...)

My question is: is it good design to continue to use the paradigm, or
should export the functions into them global namespace and use them that
way instead? Furthermore, what is the advised way to handle cases where
the custom extension at hand isn't supported by your driver? I've been
simply OSG_WARN'ing in my drawImplementation and then immediately
returning.

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


Re: [osg-users] osgWidget documentation?

2011-07-28 Thread Jeremy Moles
On Thu, 2011-07-28 at 14:22 +0200, Daniel Cámpora wrote:
 The examples don't contain exactly what I want to do. I'd like to have an 
 EventHandler triggered with the mouseRelease action, but I need to keep the 
 GUIEventAdapter and GUIActionAdapter parameters. As far as I can tell, I 
 can't do this with the current mouseHandler / keyboardHandler for the 
 widgets, right?
 
 However, it would be nice to extend the functionality, so that I could avoid 
 implementing again the logic to pick the correct widget.
 
 The needs that bring up keeping the GUI parameters are so that all the 
 information can be accessed from the Release event itself. Eg say I want to 
 trigger new events only if I clicked in a widget.

Ahh, now I see what you're saying. Unfortunately, this won't be possible
without reimplementing a lot of code. What information are you missing?
Perhaps there is an alternative way to get it?

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=41710#41710
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 


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


Re: [osg-users] osgWidget documentation?

2011-07-28 Thread Jeremy Moles
On Thu, 2011-07-28 at 18:53 +0200, Daniel Cámpora wrote:
 Hi :)
 
 Well, the widget button will trigger an animation, and my whole application 
 should be aware of this. I think the best way to do this is triggering a 
 custom event on the start of the animation, so I'd need the GUIActionAdapter 
 for my purposes.

 Nevermind, I'll go for a custom EventHandler then. I only wanted to know if 
 this was the best solution I could go for, taking into account the amount of 
 effort you've already put into the widgets :)

If you want to inject fake events into the system, the WindowManager
already has an osgViewer::View* you can use to cal -getEventQueue() on
from within your callback.

bool MyClass::mouseReleased(
double x,
double y,
const osgWidget::WindowManager* wm
) {
...
wm-getView()-getEventQueue()-addEvent(YourCustomEvent);
}

Would this work? I could still be misunderstanding something, or making
assumptions (wrongly) about what I remember of osgGA. :)

 Thanks a lot for answering my questions, Jeremy,
 
 Cheers,
 
 Daniel
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=41717#41717
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 


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


Re: [osg-users] NVidia 275-series Driver Bug

2011-07-27 Thread Jeremy Moles
On Wed, 2011-07-27 at 12:06 +0400, Sergey Polischuk wrote:
 Hi Jeremy
 
 You can try to append [] to array uniform name string when create 
 osg::Uniform, mb this helps.

It won't because it seems that internally OSG changes:

Color

...to...

Color[0]

...even, on non-array Uniforms.

If I edit Program.cpp and remove this behavior (that is, the appending
of the [0] to uniform names), it works again. This issue was also
discussed briefly here:

http://forum.openscenegraph.org/viewtopic.php?t=1828

Robert responded saying it was truly a bug with the driver, which may
still be the case. However, if I write a small, pure OpenGL application,
EITHER syntax works (Color or Color[0]). If it is a driver bug, it
is only one that is exercised by by some state leakage or similar...

My fear is that this is going to remain an issue for NVidia drivers
going forwards, but we'll have to see... perhaps someone with more
authoritative knowledge can comment on why this could be happening.

 27.07.2011, 09:51, Jeremy Moles jer...@emperorlinux.com:
  On Thu, 2011-06-16 at 14:08 -0400, Jeremy Moles wrote:
 
   Hello folks! Anyone here using the 275 series of NVidia drivers?
   (Doesn't matter what OS, the bug is on Linux and Windows for me...)
 
   It appears that this driver doesn't understand GLSL arrays anymore. At
   least, not like it used to. Crazy, huh? Yeah, I thought so too.
 
   I've attached a __VERY__ simple application demonstrating this. If
   anyone has a sec (particularly Mike Wieblen), I'd be interested to see
   if they could compile it and perhaps shed some light on this mystery. :)
 
   I've been googling and checking the NVidia forums, but so far nothing.
 
  There have been a few replies to this original thread, and I'm not
  trying to beat a dead horse here, but I recently purchased a video card
  that is ONLY support by 275+ (in Linux). So I'm back to investigating
  this issue.
 
  If I use GLSL arrays via OSG, as demonstrated in the example app, it
  completely misbehaves. However, non-array uniforms are just fine.
 
  Interestingly, if I write a purse OpenGL application using GLSL arrays,
  that works just fine. Is it possible there's some kind of bug in OSG
  that these newer drivers expose? I don't imagine they're going to fix
  this for OSG, so eventually people will have to upgrade to 275 and
  beyond...
 
  I've been trying to track down the issue, but have had no luck so far.
  I'll keep investigating, but if anyone has acquired any NEW information
  in the last month, that would be stellar. :)
 
   ___
   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


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


Re: [osg-users] osgWidget documentation?

2011-07-27 Thread Jeremy Moles
On Wed, 2011-07-27 at 19:17 +0200, Daniel Cámpora wrote:
 Hello again, Jeremy,
 
 I'm digging into this topic of the EventHandlers for the Widgets. Before 
 implementing my own EventHandler for what I'm trying to do, I'm looking at 
 how does MouseHandler works to see if I can use it.
 
 In an effort to track down what happens when the MouseHandler enters into 
 action after a mouse action, I can see the responsibility is passed to the 
 WindowManager. For instance, by looking at _handleMouseReleased:
 
 
 Code:
 bool WindowManager::_handleMouseReleased(float x, float y, bool down) {
 down = false;
 if(!_lastPush) return false;
 Event ev(this, EVENT_MOUSE_RELEASE);
 setEventFromInterface(ev, _lastPush);
 bool handled = _lastPush-callMethodAndCallbacks(ev);
 _lastPush = 0;
 return handled;
 }
 
 
 
 An object of type EventInterface is in charge of executing 
 callMethodAndCallbacks, which at last calls a virtual method mouseRelease, 
 that can be overriden.
 
 I'm confused about the use of the term callback in the EventInterface. Is 
 this a callback or an event triggered from the event handler? Or maybe it's 
 used for both?

All are possible. You can either create a standalone callback object
totally independent of any Window or Widget, you can use a special
overridden method, or you can combine the two. This is what I meant when
I said earlier I tried to support too much at once. :) The method is
always called first, then all callbacks (until one returns true, at
which point they stop).

There are examples of both kinds of event handling in the source.

 I want to develop an EventHandler separate from the widget itself. Can I 
 extend your code in some manner to achieve this, or should I go for a totally 
 custom EventHandler?

 Thank you!
 
 Daniel
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=41671#41671
 
 
 
 
 
 ___
 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] When Patents Attack

2011-07-26 Thread Jeremy Moles
http://www.thisamericanlife.org/

For those of you who live in the US, this was a great, GREAT episode of
This American Life on NPR last weekend. It talks about how absolutely
insane the patent system is in the US. It's so absurd and depressing I
honestly want to stop being a programmer and become an IP lawyer just so
I can fight these guys.

I wonder... how long will it be before these extortionists worm their
way out of the mobile software market and into the games and
system-level world? We avoid some of the heat now just because we aren't
on the radar, but it won't be long before someone is awarded a patent
for A System And Method For Dynamically Colorizing Triangular Regions
In Multidimensional Space and we're all having to pay royalties...

And it wouldn't matter that the patent would be absolute crap; unless
you have the millions required to fight it in court, you're screwed.
Prior art or otherwise. It isn't about who is right or wrong it seems,
but rather, who has more money to litigate.

So frustrating...


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


Re: [osg-users] osgWidget documentation?

2011-07-26 Thread Jeremy Moles
On Tue, 2011-07-26 at 18:16 +0200, Daniel Cámpora wrote:
 Hi Jerome,
 
 After some research and code reading, osgWidgets are much clearer to me. Once 
 I realized the WindowManager - Window - Widgets structure, everything went 
 smoother. I have a couple of questions.
 
 Is there a method to access or to know which are the widgets a Window has? 
 I'm working with a Canvas Window right now. Looking at the Window definition 
 doesn't add any light to this. I've developed a wrapper on top of this, to be 
 able to list the Widgets, modify them and so on.

You can use the interface provided by the Window's MatrixTransform
parent class (that is, getChild()) or you can use the interface provided
by UIObjectParent. The second is probably preferred.

 When I modify a widget after attaching it to the Window, I need to call 
 resize for it to be computed correctly, but I have the feeling I'm resizing 
 all the Window, where I might be well off just by resizing the Widget I 
 just modified. Is there a reason why this can't be done in this way? Probably 
 I don't fully understand the process of resizing.

osgWidget has no concept of a Window's damaged region; for this
reason, you must always call resize on the Window to get accurate
results. There are ways to cheat it, but I've never tested them...

 From the addremove example from the sources, I see we can either set a mask 
 within the widget (like in Button), or add callbacks in the Window. Is 
 there a preference on doing this? E.g., in the addremove example the 
 clickable items change their color from within the widget, whereas in the 
 canvas example this is triggered by a callback in the Window. Are there any 
 efficiency considerations on this?

You MUST set an event mask to get the events in the first place. This
seems like two different questions, perhaps? :)

 Thanks! :)
 
 Daniel
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=41630#41630
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 


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


Re: [osg-users] osgWidget documentation?

2011-07-26 Thread Jeremy Moles
On Tue, 2011-07-26 at 20:13 +0200, Daniel Cámpora wrote:
 Hello again :),
 
 
 Jeremy Moles wrote:
  
  
   From the addremove example from the sources, I see we can either set a 
   mask within the widget (like in Button), or add callbacks in the 
   Window. Is there a preference on doing this? E.g., in the addremove 
   example the clickable items change their color from within the widget, 
   whereas in the canvas example this is triggered by a callback in the 
   Window. Are there any efficiency considerations on this?
   
  
  You MUST set an event mask to get the events in the first place. This
  seems like two different questions, perhaps? :)
  
 
 
 Sorry, I was confused by the addremove example. I'm familiar with the 
 nodemasks, but I found the example a little bit confusing given the fact it 
 overrides methods to be traversed by the EventHandler (which is hidden in the 
 createExample method) and sets callbacks.
 
 Thanks!

I get a lot of questions about this via e-mail. In the next version of
osgWidget, I plan on making only ONE way to respond to events. I got a
bit carried away back in those days... :)

 Daniel
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=41638#41638
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 


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


Re: [osg-users] NVidia 275-series Driver Bug

2011-07-26 Thread Jeremy Moles
On Thu, 2011-06-16 at 14:08 -0400, Jeremy Moles wrote:
 Hello folks! Anyone here using the 275 series of NVidia drivers?
 (Doesn't matter what OS, the bug is on Linux and Windows for me...)
 
 It appears that this driver doesn't understand GLSL arrays anymore. At
 least, not like it used to. Crazy, huh? Yeah, I thought so too.
 
 I've attached a __VERY__ simple application demonstrating this. If
 anyone has a sec (particularly Mike Wieblen), I'd be interested to see
 if they could compile it and perhaps shed some light on this mystery. :)
 
 I've been googling and checking the NVidia forums, but so far nothing.

There have been a few replies to this original thread, and I'm not
trying to beat a dead horse here, but I recently purchased a video card
that is ONLY support by 275+ (in Linux). So I'm back to investigating
this issue.

If I use GLSL arrays via OSG, as demonstrated in the example app, it
completely misbehaves. However, non-array uniforms are just fine.

Interestingly, if I write a purse OpenGL application using GLSL arrays,
that works just fine. Is it possible there's some kind of bug in OSG
that these newer drivers expose? I don't imagine they're going to fix
this for OSG, so eventually people will have to upgrade to 275 and
beyond...

I've been trying to track down the issue, but have had no luck so far.
I'll keep investigating, but if anyone has acquired any NEW information
in the last month, that would be stellar. :)

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


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


Re: [osg-users] osgWidget documentation?

2011-07-22 Thread Jeremy Moles
On Fri, 2011-07-22 at 10:50 +0200, Daniel Cámpora wrote:
 Hi community,
 
 I've bumped into using osgWidget for an application I'm developing. It seems 
 very powerful and customizable, yet I can't find any documentation / tutorial 
 on how to use it.
 
 Is there any documentation available for osgWidget?

Not yet. :(

But feel free to use the lists to ask any question, or add me via
googletalk (cubic...@gmail.com) and ask me directly...

 Thank you!
 
 Cheers,
 Daniel
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=41560#41560
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 


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


Re: [osg-users] ANN: osgText::TextNode API

2011-07-08 Thread Jeremy Moles
Hey guys, I'm bumping this as I posted it over a holiday weekend and it
may have fell through the cracks. I'm also about to submit the first
rough draft of osgText::TextNode.

It will build standalone, but you'll need to replace Style/Style.cpp in
your real OSG trunk first with the files from the patches directory.
So, I don't expect many people to do this (quite yet). :)

What I'm really looking for are ideas on how to continue doing drop
shadow and outline in 2D text. osgPango does this by rasterizing two
textures and then multitexturing...

I was trying to think of way to do it just GLSL, but I can't quite come
up with anything.

On Fri, 2011-07-01 at 13:19 -0400, Jeremy Moles wrote:
 Hello all! In just a few days (I will finish the code over the holidays)
 I'm going to be submitting a bit of code to Robert to evaluate for
 inclusion into OSG proper. It is a continuation of his experimentation
 with a new text interface called TextNode.
 
 TextNode diverges a great deal from what you might be used to with Text
 and Text3D objects, but in the end the transition (if Robert accepts
 it :)) will be worth it. The API has been cleaned up, internal data is
 much easier to get at, and the rendering and layout backends have become
 pluggable.
 
 Before I finish up the last bits so that a first beta version can be
 submitted and people can begin experimenting with it, I'd like to
 solicit some input.
 
 1) I'm dropping all support for the FFP. I mean, c'mon. It makes the
 code substantially harder to maintain and understand. If this causes the
 code to be rejected (or perhaps results in Text and Text3D staying
 around for a bit longer to support FFP), then so be it. :) In lieu of
 this, however, I'd like some opinions on which version of GLSL I should
 target and how well that version is currently supported by OSG.
 
 2) TextNode (3D) glyph support is working quite well; it wasn't hard,
 since most of the code was already there in the backend. Each glyph is
 cached based on its Style and Font, put into a PAT, and then finally all
 of the text is squished into a top-level MatrixTransform. I continue to
 use the setAlignment() and setAxisAlignment() API, but obviously you're
 free to do whatever you like. How does this sound to everyone?
 
 3) TextNode (2D) is still going to require a bit of work at the time of
 the first submission. In the new API, osg::Geometry objects are
 constructed using quads textured with the 2D glyphs and, again, packaged
 into a top-level MatrixTransform. A remaining (serious) question is how
 to do drop-shadows and outlines?
 
 4) As some of you may know, I am also the author of osgCairo and
 osgPango. Both of these nodekits came to be as I was working on
 osgWidget, which--combined with getting sick--seriously sidetracked that
 project. :) (I haven't forgot about osgWidget though--hang in there!)
 This isn't an attempt to plug that software, but rather me posing a
 question I've asked before:
 
   4.a) The 2D quality provided by osgPango simply cannot be 
   matched by anything any of us could do by hand. This is
   partly due to osgPango's massive user base and its main
   developers, but it is also due to the fact that the Glyph
   rasterizer is Cairo. Now, I won't be so bold as to ask OSG 
   to accept osgPango (yet :)), but what I would like to do is
   provide a way for Cairo to do the glyph rasterization instead of
   doing it manually with Freetype. This is the approach osgPango
   takes, and it lets osgPango provide a very powerful glyph
   effect API. Let me elaborate below...
 
   In current 2D OSG, you request a string of text. Each
   character is iterated over and the backend calls FT_Load_Char
   to render each glyph at a particular resolution, at which
   point that glyph is put into a texture atlas to be reused
   later.
 
   If we supported Cairo as a rasterizing backend, we would instead
   be given the glyph information for each character as a vector
   path and would have the freedom to do whatever Cairo's drawing
   API allows with it. In the most basic case, this would be a
   simple fill() operation, but as you can see from the osgPango
   screenshots: http://www.jeremymoles.com/osgPango , a lot of
   interesting things can be done when you have a vectorized
   path of a glyph. :)
 
 Don't misunderstand me though: osgPango isn't going anywhere! The layout
 support alone provided by osgPango is incredible, and it is able to
 provide additional information to the rasterizer for higher quality
 fonts (it also supports more than just Freetype; Atsui and the Windows
 font backend, for example). It also understands just about every
 language and locale out there, so text is always positioned properly.
 But I would like to at least like to pose the idea of using Cairo as the
 rasterizer, or at least providing a plugin (since it is the freetype
 plugin in the osgPlugins directory

[osg-users] ModelView/Projection Matrices From Camera

2011-07-05 Thread Jeremy Moles
Hey guys, I have a really quick question. I'm trying to debug a piece of
code and what I need is access to the current MV/Proj matrices as
affected by the Viewer's active camera.

I see that they can both be queried from an osg::State object, though
I've never had to interface directly with this.

Does anyone have any quick tricks?

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


Re: [osg-users] ModelView/Projection Matrices From Camera

2011-07-05 Thread Jeremy Moles
On Tue, 2011-07-05 at 10:38 -0600, Paul Martz wrote:
 On 7/5/2011 10:10 AM, Glenn Waldron wrote:
  I usually pull them from the CullVisitor/CullStack during the cull 
  traversal.
 
 Right -- During cull you can access these from the CullVisitor:
  osg::RefMatrix* view = cv-getModelViewMatrix();
  const osg::Camera* cam = cv-getCurrentCamera();
  const osg::Matrix proj = cam-getProjectionMatrix();
  const osg::Viewport* vp = cam-getViewport();
 
 If you're trying to get these during draw, you need to get them from 
 osg::State:
  const osg::State* state = renderInfo.getState();
  const osg::Matrix view = getModelViewMatrix();
  const osg::Matrix proj = getProjectionMatrix();
  const Viewport* vp = getCurrentViewport();
 
 -Paul

Thanks Paul and Glenn. I have a cool example coming demonstrating Signed
Distance Field rendering, particularly as it pertains to text (inspired
by an e-mail from a fellow named John Smith. It's exceptionally cool
stuff, I'm just having trouble understanding the relationship between
the current ViewMatrix and and the algorithm's idea of scale.

I get decent results with a 1:1 ratio, but there's more to it than that.
Much reading shall take place!

 
  Glenn Waldron / Pelican Mapping / @glennwaldron
 
 
  On Tue, Jul 5, 2011 at 12:01 PM, Jeremy Moles jer...@emperorlinux.com
  mailto:jer...@emperorlinux.com wrote:
 
  Hey guys, I have a really quick question. I'm trying to debug a piece of
  code and what I need is access to the current MV/Proj matrices as
  affected by the Viewer's active camera.
 
  I see that they can both be queried from an osg::State object, though
  I've never had to interface directly with this.
 
  Does anyone have any quick tricks?
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org 
  mailto: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


[osg-users] ANN: osgText::TextNode API

2011-07-01 Thread Jeremy Moles
Hello all! In just a few days (I will finish the code over the holidays)
I'm going to be submitting a bit of code to Robert to evaluate for
inclusion into OSG proper. It is a continuation of his experimentation
with a new text interface called TextNode.

TextNode diverges a great deal from what you might be used to with Text
and Text3D objects, but in the end the transition (if Robert accepts
it :)) will be worth it. The API has been cleaned up, internal data is
much easier to get at, and the rendering and layout backends have become
pluggable.

Before I finish up the last bits so that a first beta version can be
submitted and people can begin experimenting with it, I'd like to
solicit some input.

1) I'm dropping all support for the FFP. I mean, c'mon. It makes the
code substantially harder to maintain and understand. If this causes the
code to be rejected (or perhaps results in Text and Text3D staying
around for a bit longer to support FFP), then so be it. :) In lieu of
this, however, I'd like some opinions on which version of GLSL I should
target and how well that version is currently supported by OSG.

2) TextNode (3D) glyph support is working quite well; it wasn't hard,
since most of the code was already there in the backend. Each glyph is
cached based on its Style and Font, put into a PAT, and then finally all
of the text is squished into a top-level MatrixTransform. I continue to
use the setAlignment() and setAxisAlignment() API, but obviously you're
free to do whatever you like. How does this sound to everyone?

3) TextNode (2D) is still going to require a bit of work at the time of
the first submission. In the new API, osg::Geometry objects are
constructed using quads textured with the 2D glyphs and, again, packaged
into a top-level MatrixTransform. A remaining (serious) question is how
to do drop-shadows and outlines?

4) As some of you may know, I am also the author of osgCairo and
osgPango. Both of these nodekits came to be as I was working on
osgWidget, which--combined with getting sick--seriously sidetracked that
project. :) (I haven't forgot about osgWidget though--hang in there!)
This isn't an attempt to plug that software, but rather me posing a
question I've asked before:

4.a) The 2D quality provided by osgPango simply cannot be 
matched by anything any of us could do by hand. This is
partly due to osgPango's massive user base and its main
developers, but it is also due to the fact that the Glyph
rasterizer is Cairo. Now, I won't be so bold as to ask OSG 
to accept osgPango (yet :)), but what I would like to do is
provide a way for Cairo to do the glyph rasterization instead of
doing it manually with Freetype. This is the approach osgPango
takes, and it lets osgPango provide a very powerful glyph
effect API. Let me elaborate below...

In current 2D OSG, you request a string of text. Each
character is iterated over and the backend calls FT_Load_Char
to render each glyph at a particular resolution, at which
point that glyph is put into a texture atlas to be reused
later.

If we supported Cairo as a rasterizing backend, we would instead
be given the glyph information for each character as a vector
path and would have the freedom to do whatever Cairo's drawing
API allows with it. In the most basic case, this would be a
simple fill() operation, but as you can see from the osgPango
screenshots: http://www.jeremymoles.com/osgPango , a lot of
interesting things can be done when you have a vectorized
path of a glyph. :)

Don't misunderstand me though: osgPango isn't going anywhere! The layout
support alone provided by osgPango is incredible, and it is able to
provide additional information to the rasterizer for higher quality
fonts (it also supports more than just Freetype; Atsui and the Windows
font backend, for example). It also understands just about every
language and locale out there, so text is always positioned properly.
But I would like to at least like to pose the idea of using Cairo as the
rasterizer, or at least providing a plugin (since it is the freetype
plugin in the osgPlugins directory that actually is responsible for
building the glyph atlas) to do this. 

---

I TRULY feel like if we can get this UI stuff under control (which is
why I started working on osgWidget, osgCairo, osgPango) we can
absolutely establish OSG as the premiere OpenGL toolkit. Hopefully I can
make enough strides in this area in my freetime so that one day I can do
it FULL TIME for a living. :) If anyone is familiar with Scaleform (and
if you've played any games made in the last 5 years, you can't have
missed it), something of that visual quality and style is what I
envision for OSG one day (minus the Flash absurdity)...



  1   2   3   4   5   >