Re: [osg-users] How to make sure that both the back and the front side of a polygon are lit...

2010-06-29 Thread Alberto Luaces
Hi Sunil,

Sunil S Nandihalli writes:

 Hello everybody,
  I would like to have both the front and the back side of the polygons I draw 
 lit. Right now I have specified the normals and only the side which is on the 
 same side as that of the normals is being lit..
 Should I render the same-geometry twice and add normals to it so that it is 
 lit on both sides.. I realized this might not be the right way to do it.. 
 Does any of you have any suggestion?

You are already doing it right. Just render once, disable the face
culling with osg::StateSet in order to allow both sides to be seen, and
specify a material for the back side or at the same time you defined
the front one.

-- 
Alberto

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


Re: [osg-users] Future of osgIntrospection + genwrapper, volunteers required.

2010-06-29 Thread Wang Rui
Hi Mike,

It would be appreciated if you and others can contribute to the 'newborn'
osgIntrospection project. I've just finished updating all the cmake scripts
and a new example which explains how to use the wrappers to construct and
view a simple scene. Now people who use osgIntrospection in there own
applications can have a complete test to see if there are any bugs or
inconvenience.

There are some more work in my todo list at present:
1. Merge the genwrapper utility and see if we can have a set
of custom commands to automatically generate and compile wrappers from an
input OSG directory. With this, we can remove those wrapper
code directories out of the osgIntrospection source in the future.
2. Add a few more examples to help people be familar with this powerful
library and make use of it. The newly submitted simple_example would be a
not bad example, I hope. :)
3. Add examples and front-ends for binding OSG with other languages if
possible.
4. Make sure the project can work on most platforms.
I'm not used to the packaging on debian and ubuntu. Would you like to use
CPack to create tarballs and automatically setting up packages? I believe it
will be really useful to developers who prefer prebuilts.

To submit changes, just start new threads on the osg-users (or
osg-submissions? Is it permitted, Robert?). I'm looking forward to work with
you to improve the osgIntrospection project.

Cheers,

Wang Rui


2010/6/29 Mike Wozniewski m...@mikewoz.com

 Hi Robert / Wang Rui,

 I'd be willing to help on this as well. Particularly, I'd like to help get
 a debian ( ubuntu) package out soon that includes osgIntrospection and
 genwrapper.

 Robert, can you add genwrapper to the new repository?

 Specific things that I am interested in:
 - ensuring that genwrapper builds properly
 - ensuring that genwrapper can find OSG's headers and build the wrappers
 - when the 2.9.9 tag is made for OSG, make a corresponding tag for
 osgIntrospection (and a tarball)
 - use the tarball to set up packaging for debian and ubuntu launchpad

 I'm more familiar with autotools, and would be willing to do all this in
 that style. However, cmake seems easy enough, so I could tackle this using
 cmake assuming that I could ask everyone some questions.

 -Mike

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


[osg-users] OT: Magic Planet

2010-06-29 Thread J.P. Delport

Hi all,

has anyone used something like this before?

http://www.globalimagination.com/products.html

jp


--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.


This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.


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


Re: [osg-users] How to make sure that both the back and the front side of a polygon are lit...

2010-06-29 Thread Tony Horrobin

Hi Sunil,

Just to be clear, you also need to specify a two-sided light model to 
make OpenGL apply both front and back materials.

The osg::LightModel class allows this.

Cheers,

-Tony

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


Re: [osg-users] Plugin to Node Kit?

2010-06-29 Thread Robert Osfield
Hi Brad,

The plugins are designed to be entirely encapsulated within themselves
and not to export any symbols, save for any C function entry points
for enabling static linking of plugins.  This decoupled approach does
mean that you don't have any public interface to access internals
classes/methods.  In general this isn't an issue though.

What specifically about the DirectShowTexture header do you need
access to?  It may be that you do what you want within any specific
access to it.  Keeping a loose coupling is generally the best
programming approach as it enables you to change you backend
implementation easily - such as if you needed to support a new
platform.

Robert.

On Tue, Jun 29, 2010 at 12:51 AM, Brad Huber br...@procerusuav.com wrote:
 Hello,



 I am curious what the path is for a osg plugin to become a node kit (or
 portions of it).  Does anyone have some information / insight?



 The reason that I ask is that I’m trying to use the Directshow texture class
 that is currently in the osg directshow plugin.  I do not believe a plugin
 is sufficient for what I’m trying to do because I want to work directly with
 the low-level directshow graph. As I understand, this is something that
 cannot be easily done via the file based plugin architecture.  For example I
 want to instantiate a rather complex graph (programmatically from a GUI) and
 then connect a pin to the Directshow texture.



 Perhaps I’m not seeing the correct way to go about this, if so, I would love
 some advice.  Otherwise- what is the process to go from plugin to node kit
 especially for a platform specific library such as directshow.



 Thanks for your input



 -Brad

 ___
 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] Shader composition, OpenGL modes and custom modes

2010-06-29 Thread Mathias Fröhlich

Hi Robert,

On Monday 28 June 2010, Robert Osfield wrote:
 Yes, even if we tweak the API a bit in StateSet any new elements will
 sorted virtue of being in StateSet.  Whatever we do StateSet's will
 remain the container for all things state in the scene graph, and the
 what basis of coarsed grained state sorting and lazy state updating
 that the OSG provides by default.
Ok.

  So in effect you will know the final shader combination for a render leaf
  at cull time.
  Right?

 Yes, once you've traversed down the graph to the osg::Drawable leaves
 you know all the state inheritance and can compute the final program
 and uniform combination that will be required.
Ok.

  Wouldn't it be better to match the final shaders programs at cull time
  instead of draw time?

 The only reason there might be an advantage is that if you draw
 traversal was more CPU limited than the draw.  In general I would
 expect the cost of selecting the appropriate programs during draw will
 be very low relative to the cost of dispatching the data itself.
Yes.

 The only part that might be expensive is the composition of the shader
 mains and then compiling these main shaders, but again the cost of
 composing the main shaders is likely to be much lower than the OpenGL
 side of compiling them, and you have to do the compiling in the draw
 traversal any so the saving again is likely to be be pretty small if
 detectable.
True, compiling is expensive.
But that is exactly what should be better done just once when a new shader 
combination appears. The final program should just be stored and reused once 
it is compiled *and* linked.

I am sure that compiling a shader is expensive. But I am also sure that 
linking is *not* about for free.
I expect that drivers will again do some optimizations once linking happens. 
For example there are GPU's out there which do not have jump instructions. In 
this case, linking must at least do inlining again.
Also there are plenty of optimization opportunities that start to be available 
when the whole program is known. So, I expect that at link time the shader 
optimizer is started again and again improoves the shader code.

So, what I think is that we need minimize shader compilation as well as shader 
*linking* as much as possible. If the implementation you have in mind really 
does this, then fine.
If you intent to relink on about every StateAttribute::compose(osg::State) 
call, I expect to run into problems.

 Doing more work in the cull will mean we'll have to pass more data to
 draw which itself may result in a performance overhead as the extra
 data structures will need to be dynamically allocated/destroyed.
Sure, malloc is to be avoided for real time.
Anyway, I am thinking more about something that computes a probably scalar key 
or pointer to an already existing object that is able to identify the final 
shader program combination in the cull stage and sets that key into the 
render leaf.
On apply this key is taken to apply the opengl shader object containing the 
already finished shader program. May be this key could be the to be cached 
final shader program.
So, no per draw dynamic memory management with this kind of approach.

 Right I want to get things working, the API and the backend are going
 to be new and complex enough that I want to take the route of least
 resistance and not worry to much about small possible optimization.
 Moving more work into cull might be an optimization that would be
 worth doing, but then it could just as easily be worse for
 performance.
Ok.

The only thing that might then turn out problematic is that then there is the 
StateAttribute::compose(State) call which directly operates on the State 
object. Once this is in place, backward compatibility will never make that go 
away. In effect this will make a switch to a 
StateAttribute::compose(CullTimeShaderComposer) call impossible...
That is the reason I am thinking about that current proposal for such a long 
time. May be the State should provide such a 'ShaderCompositon' object as a 
member and you let the state attribute work on this member of the State?
Then this could be moved easier if this turns out to be critical?

So, again the critical thing from my point of view:
If you can make sure that we never relink during draw once no new shader 
combination appears, I believe we are fine.

Greetings

Mathias

-- 
Dr. Mathias Fröhlich, science + computing ag, Software Solutions
Hagellocher Weg 71-75, D-72070 Tuebingen, Germany
Phone: +49 7071 9457-268, Fax: +49 7071 9457-511
-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier, 
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196 


___
osg-users mailing list
osg-users@lists.openscenegraph.org

Re: [osg-users] Future of osgIntrospection + genwrapper, volunteers required.

2010-06-29 Thread Robert Osfield
Hi Wang Rui,

Good to see osgIntrospection updates coming through ;-)

On Tue, Jun 29, 2010 at 8:51 AM, Wang Rui wangra...@gmail.com wrote:
 To submit changes, just start new threads on the osg-users (or
 osg-submissions? Is it permitted, Robert?).

It would be fine to keep discussions of osgIntrospection/genwrapper on
osg-users and submissions on osg-submissions.  While these are now a
separate project we are still all one of the same family.  Personally
I'd use osg-submissions for code changes as I find it far easier to
use it as a clear in tray, sending code changes to osg-users is really
fraught with missing stuff amongst the higher traffic.

One thing you might also consider is adding Mike to the list of
writers, Jose Luis Hidalogo will need to set this up, but as this
doesn't normally take too long to sort out.  Is suspect with such a
small project it probably won't be necessary to have too many writers.

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


Re: [osg-users] Shader composition, OpenGL modes and custom modes

2010-06-29 Thread Robert Osfield
Hi Mathias,

2010/6/29 Mathias Fröhlich m.froehl...@science-computing.de:
 So, what I think is that we need minimize shader compilation as well as shader
 *linking* as much as possible. If the implementation you have in mind really
 does this, then fine.  If you intent to relink on about every
 StateAttribute::compose(osg::State) call, I expect to run into problems.

I think you've mis-understood my intentions.  My plan has been to
cache the osg::Program and main shaders once they are generated,
Roland's implementation also takes the route.  Calls to
StateAttribute::compose(osg::State) or it equivalent would only been
done when a new shader combination is required.


 The only thing that might then turn out problematic is that then there is the
 StateAttribute::compose(State) call which directly operates on the State
 object. Once this is in place, backward compatibility will never make that go
 away. In effect this will make a switch to a
 StateAttribute::compose(CullTimeShaderComposer) call impossible...

I don't think a CullTimeShaderComposer is a good idea, but a subclass
from ShaderComposer is fine, so I don't think there is a tightly
coupling issue at all.  We just need to get the design right so we can
alter subclass from ShaderComposer as well as write our own sets of
shaders.

 That is the reason I am thinking about that current proposal for such a long
 time. May be the State should provide such a 'ShaderCompositon' object as a
 member and you let the state attribute work on this member of the State?

As for the end of last week osg::State already has a ShaderComposer*
get/setShaderComposer method :-)

ShaderComposer is just a placeholder right now.

 Then this could be moved easier if this turns out to be critical?

I think we'll need to be pretty easy going with what the final design
is until we've played with actually implementing the code.  Is pretty
rare for a design to work perfectly once you start trying to solve
real problems with it.  For me the real test will be how well we can
implement the fixed function pipeline within shader composition - if
this works neatly and conveniently then we'll be well on track.

 So, again the critical thing from my point of view:
 If you can make sure that we never relink during draw once no new shader
 combination appears, I believe we are fine.

I believe we'll all be in agreement here.  This is certainly what I'm
aiming for, all the designs I'm working on use a program cache as a
fundamental part of the design, with state changes minimized.  I don't
see it all as much different to what we do know with creating texture
objects, VBO's, display lists, it's just we'll be operating on a
slightly higher level, it should all be the same principle - the OSG
worries about doing things efficiently, and the scene graph developer
just concentrates on composing the scene graph and state classes to
get the result they want.

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


Re: [osg-users] Shader composition, OpenGL modes and custom modes

2010-06-29 Thread Robert Osfield
I've not at the computer full time for the last couple of days so
haven't been able to push the shader composition implementation on
yet.  Design wise I've been doing bits here and there.  My latest
thought is that we probably need to encapsulate the component that
will go to make up shader composition as a single class/object.  This
class would contain a list of required shaders, the list of shader
modes, and the shader main code injection rules.  What to call this
class is a problem... perhaps ShaderSet?  ShaderComponent?
ShaderChunk?  Thoughts?

For my own design doodling I've run with the name ShaderSet for this
class, so will follow this in rest of the email, if we go for
something different later then so be it.  The role of the ShaderSet
would be:

  1) Provide a way of encapsulating all the details required to
contribute a single chunk
 of functionality that will be combined with other active
ShaderSet to provide final
 composed osg::Program.

  2) Provide a convenient mapping of a single ShaderSet representing a single
  implementation that can be shared by multiple osg::StateAttribute objects,
  for instance all osg::Light objects would shader a single
ShaderSet for all
  directional lights, another ShaderSet for all positional lights
etc.  If different
  state attribute objects shader the same ShaderSet then there it
will be easily
  to test whether shaders are the same simply be testing the pointer value,
  we needn't look into the contents.

  This approach works well for the OSG right now with how we manage
  osg::StateSet or the StateAttribute within them, so I'm pretty
comfortable that
  this approach will be useful when doing shader composition and keeping the
  costs of lazy state updating down.

  3) The ShaderSet would contain list osg::Shader objects, these osg::Shader
  objects would target which ever part of the overall program that
the ShaderSet
  effects - be in multiple osg::Shader for vertex programs, one of
vertex program
  one for fragment, or any combination.  The individual
osg::Shader objects could
  also be shared by multiple ShaderSet where appropriate.

   4) The StateAttribute would have a ShaderSet which defines all the shader
  setup required, this ShaderSet would typically be shared by all
instances of
  that type of StateAttribute.   The StateAttribute also have
zero more uniforms
  that pass in values to the shaders in the ShaderSet, these
uniforms wouldn't
  typically be shared, but would be solely owned by each separate
StateAttribute
  object.

  The StateAttribute's ShaderSet would only ever be queried if the
shader modes
   associated with that ShaderSet and hence StateAttribute are enabled, and
   no cached osg::Program for the current configuration of enabled
shader modes
   is available.

   5) It might well be that some StateAttribute have unifoms but no
ShaderSet, it
   might also be appropriate for some StateAttribute to have no uniforms and
   a ShaderSet.  It might even be appropriate for a single
StateAttribute to have
   multiple ShaderSet depending upon what mode it is in - for
instance osg::Light
   might be implemented in such a way that you have one ShaderSet for a
   directional light, and one ShaderSet for position light,
another for spot lights,
   another for per pixel lighting etc, and select the appropriate
one depending
   upon the set up of the osg::Light.

   6) Given osg::StateSet already has support for managing osg::Uniform directly
   perhaps we might even want to make it possible to assign
ShaderSet directly
   along side them rather than nesting them within StateAttribute.  A pure
   shader composition approach could do this, but for seamless
support of existing
   fixed function StateAttribute based scene graph we won't be
able to just this.
   However, have two ways of doing the same thing might just lead
to confusion...
   so it's something I think we just need to implement and test to
see how we get
   on.

Anyway these are my latests thoughts.  I will be out for much of
today, but later in the week should get more time to start
implementing some code to start experimenting with basic shader
composition.

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


Re: [osg-users] [osgPlugins] OBJ plugin loader places model at wrong position and with wrong attitude

2010-06-29 Thread Gianni Ambrosio
Hi,
is there a way to set noRotation option again to the default value?

Regards
Gianni

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





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


[osg-users] setting a color to material

2010-06-29 Thread Nitin Rangari
hi all,

 can  i set a both color array and material in one geometry?

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


Re: [osg-users] setting a color to material

2010-06-29 Thread Trajce (Nick) Nikolov
yes. You can set the color directly for the Geometry and the Material as a
State

-Nick


On Tue, Jun 29, 2010 at 5:37 PM, Nitin Rangari rangari.niti...@gmail.comwrote:

 hi all,

  can  i set a both color array and material in one geometry?

 thanks,
 Nitin


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


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


Re: [osg-users] [osgPlugins] OBJ plugin loader places model at wrong position and with wrong attitude

2010-06-29 Thread Alberto Luaces
Gianni Ambrosio writes:

 Hi,
 is there a way to set noRotation option again to the default value?

I don't know if it is possible from the command line. You could
osgconvert the files that are in odd orientations.

Programmatically, just don't use the same osgDB::Options object in the
next read.

-- 
Alberto

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


Re: [osg-users] [vpb] terrain cracks

2010-06-29 Thread issam boughanmi
sorry for the late reply !


i build another terrain with other dem and imagery and it worked fine 

i don't know why ...

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





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


Re: [osg-users] [osgPlugins] OBJ plugin loader places model at wrong position and with wrong attitude

2010-06-29 Thread Gianni Ambrosio

Alberto Luaces wrote:
 
 Programmatically, just don't use the same osgDB::Options object in the
 next read.
 

Yes Alberto, I mean programmatically.

What do you mean by that? What if I would like to use the existing 
osgDB::ReaderWriter::Options as is but just without the noRotation setting? 
If I overwrite the Options object I think I would loose all the other options.

Regards
Gianni

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





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


Re: [osg-users] Shader composition, OpenGL modes and custom modes

2010-06-29 Thread Mathias Fröhlich

Hi Robert,

On Tuesday 29 June 2010, Robert Osfield wrote:
 I believe we'll all be in agreement here.  This is certainly what I'm
 aiming for, all the designs I'm working on use a program cache as a
 fundamental part of the design, with state changes minimized.  I don't
 see it all as much different to what we do know with creating texture
 objects, VBO's, display lists, it's just we'll be operating on a
 slightly higher level, it should all be the same principle - the OSG
 worries about doing things efficiently, and the scene graph developer
 just concentrates on composing the scene graph and state classes to
 get the result they want.
Fine then.

Greetings

Mathias

-- 
Dr. Mathias Fröhlich, science + computing ag, Software Solutions
Hagellocher Weg 71-75, D-72070 Tuebingen, Germany
Phone: +49 7071 9457-268, Fax: +49 7071 9457-511
-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier, 
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196 


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


[osg-users] setFont

2010-06-29 Thread Gianni Ambrosio
Hi All,
I looked at the OSG examples in vain to understand how to load a font properly. 
OSG examples work fine if started from my dev environment (VS) but 
setFont(fonts/blablabla.ttf) does not work if I run my app normally double 
clicking on the .exe file. The osgtext example have the same problem and I 
read unable to load \fonts/fudd.ttf\ and the same for all fonts.

Is there a way in OSG to load fonts without copying the ttf file in the exe dir 
or set the file in the resources?

Regards
Gianni

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





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


Re: [osg-users] [osgPlugins] OBJ plugin loader places model at wrong position and with wrong attitude

2010-06-29 Thread Alberto Luaces
Hi Gianni,

Gianni Ambrosio writes:

 Alberto Luaces wrote:
 
 Programmatically, just don't use the same osgDB::Options object in the
 next read.
 

 Yes Alberto, I mean programmatically.

 What do you mean by that? What if I would like to use the existing 
 osgDB::ReaderWriter::Options as is but just without the noRotation setting? 
 If I overwrite the Options object I think I would loose all the other options.

Then you can use osgDB::ReaderWriter::Options::getOptionString(), remove
noRotation there and then apply it again with
osgDB::ReaderWriter::Options::setOptionString(). Or better, have two
osgDB::ReaderWriter::Options objects...

-- 
Alberto

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


Re: [osg-users] setFont

2010-06-29 Thread Alberto Luaces
Gianni Ambrosio writes:

 Is there a way in OSG to load fonts without copying the ttf file in the exe 
 dir or set the file in the resources?

Setting the environment variable OSG_FILE_PATH.

-- 
Alberto

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


Re: [osg-users] setFont

2010-06-29 Thread Jean-Sébastien Guay

Hello Gianni,


I looked at the OSG examples in vain to understand how to load a font properly. OSG examples work fine if started from my 
dev environment (VS) but setFont(fonts/blablabla.ttf) does not work if I run my app normally double 
clicking on the .exe file. The osgtext example have the same problem and I read unable to load 
\fonts/fudd.ttf\ and the same for all fonts.


TrueType fonts are loaded by the FreeType plugin (osgdb_freetype). The 
DLL for this plugin must be in your osgPlugins-version directory like 
any other plugin (loader), and if it has any depedencies (like a 
freetype DLL for example) these also must be findable by your app at 
runtime (in your PATH, or in your app's directory).


If this is all findable, then the problem might be that your path to the 
font file is not correct. A font file is like an image, you need to give 
the right path. You might want to distribute your fonts with your app to 
make sure it can find them (make sure you use fonts you can redistribute 
in this way - check the license terms for the fonts you use or use open 
source fonts).


So to sum up, a font file is like any other data file. Your path to load 
it must be correct, and OSG must have the plugin and its dependencies to 
be able to load it.


You might be thinking of the system font directory, you could use that 
by using the WINDIR environment variable and then add 
\fonts\fontname.ttf to the end, but I wouldn't advise you use that 
since then you're dependent on what fonts the user has installed, and 
it's not portable to other operating systems. Much better to find an 
open source font you like and distribute it with your app.


Hope this helps,

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


[osg-users] Rotating a vector by a quat

2010-06-29 Thread John Galt
Hi,

I am looking for an easy way to rotate a vec3d by a quat(roll, pitch, yaw). So 
if my vector is defined by (x,y,z) how do I figure out what the resultant of a 
spatial rotation of (roll, pitch, yaw) would be? I have calculated the final 
position of the vector using math but is there any other, more simpler way to 
do it in osg?

Thank you!

Cheers,
John

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





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


Re: [osg-users] setFont

2010-06-29 Thread Gianni Ambrosio
OK, so there isn't a special way to handle fonts in OSG.
Thanks, Gianni

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





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


Re: [osg-users] Transform Feedback

2010-06-29 Thread Ethan Kerzner
Hi,

I guess my first question was too vague. Sorry about that. I am still trying to 
use transform feedback on an entire scene inside osg.

I have created a CustomDrawable class with a drawImplementation that can 
perform transform feedback on anything drawn inside it. I am now trying to draw 
the entire scene inside my drawImplementation using a node visitor to traverse 
the graph and locate and draw all of the drawables with transform feedback 
enabled.

I do not understand the parameters of void draw(osg::RenderInfo renderInfo) 
const function. 

Can you please explain what information RenderInfo contains? Is the RenderInfo 
different for each drawable or global for the scene? Is it possible to 
determine the RenderInfo of a drawable?

Thanks,
Ethan

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





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


Re: [osg-users] Plugin to Node Kit?

2010-06-29 Thread Brad Huber
Robert,

Here is what I would like to do:

We have an existing app that has a GUI which builds a directshow graph
including selecting a capture device and properties on that capture device
and building the necessary intermediate filters.  If I can pass a Directshow
Pin (or pointer to pin) into the directshow texture then my work is done.
Obviously this does require the tighter coupling of which you speak.

Within the plugin architecture- the current abilities of osgDirectshow are
not expressive enough.  The alternative that I see would be way more complex
and would be something like making the plugin read the .grf file format
which allows specifying complex graphs.  Also I would need to make our app
able to write these files which it doesn't currently.  Very much overkill in
my opinion.

The third alternative would be for me to expose DirectshowTexture but not to
have commits accepted back to the community.

Thoughts?

Thanks
-Brad

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Tuesday, June 29, 2010 3:28 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Plugin to Node Kit?

Hi Brad,

The plugins are designed to be entirely encapsulated within themselves
and not to export any symbols, save for any C function entry points
for enabling static linking of plugins.  This decoupled approach does
mean that you don't have any public interface to access internals
classes/methods.  In general this isn't an issue though.

What specifically about the DirectShowTexture header do you need
access to?  It may be that you do what you want within any specific
access to it.  Keeping a loose coupling is generally the best
programming approach as it enables you to change you backend
implementation easily - such as if you needed to support a new
platform.

Robert.

On Tue, Jun 29, 2010 at 12:51 AM, Brad Huber br...@procerusuav.com wrote:
 Hello,



 I am curious what the path is for a osg plugin to become a node kit (or
 portions of it).  Does anyone have some information / insight?



 The reason that I ask is that I’m trying to use the Directshow texture
class
 that is currently in the osg directshow plugin.  I do not believe a plugin
 is sufficient for what I’m trying to do because I want to work directly
with
 the low-level directshow graph. As I understand, this is something that
 cannot be easily done via the file based plugin architecture.  For example
I
 want to instantiate a rather complex graph (programmatically from a GUI)
and
 then connect a pin to the Directshow texture.



 Perhaps I’m not seeing the correct way to go about this, if so, I would
love
 some advice.  Otherwise- what is the process to go from plugin to node kit
 especially for a platform specific library such as directshow.



 Thanks for your input



 -Brad

 ___
 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] [osgPlugins] OBJ plugin loader places model at wrong position and with wrong attitude

2010-06-29 Thread Gianni Ambrosio
Hi Alberto,

Alberto Luaces wrote:
 remove
 noRotation

probably my question is too stupid ... how can I remove it?
I tried with:

osgDB::ReaderWriter::Options* options = 
osgDB::Registry::instance()-getOptions();
options-removePluginData(noRotation)

but it does not seem to work. I mean the Options object still contains the 
noRetation string inside.

Regards,
Gianni

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





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


Re: [osg-users] [osgPlugins] OBJ plugin loader places model at wrong position and with wrong attitude

2010-06-29 Thread Gianni Ambrosio
OK, I think I didn't get the usage of the option string. I thought I could set 
a single option but it seems I have to set the whole option string again. So 
I have to parse the string to remove the noRotation substring ... if so, from 
my point of view it is not a user friendly API.

Regards
Gianni

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





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


Re: [osg-users] Plugin to Node Kit?

2010-06-29 Thread Stephan Maximilian Huber
Hi Brad,

if the only thing you want is to pass paramters / objects to the plugin,
so it sets up its stuff accordingly you can use
ReaderWriter::Options::setPluginData and extend the DirectoShow-Plugin
to use these plugin-data if available.

So you can feed you directshow-pin to the plugin and set it up
accordingly and you can submit these changes back to the community.

This should work the other way round, too. Add the data you are
interested in to the options-object, and use them afterwards.

Just thinking loud,

cheers,
Stephan



Am 29.06.10 17:57, schrieb Brad Huber:
 Robert,
 
 Here is what I would like to do:
 
 We have an existing app that has a GUI which builds a directshow graph
 including selecting a capture device and properties on that capture device
 and building the necessary intermediate filters.  If I can pass a Directshow
 Pin (or pointer to pin) into the directshow texture then my work is done.
 Obviously this does require the tighter coupling of which you speak.
 
 Within the plugin architecture- the current abilities of osgDirectshow are
 not expressive enough.  The alternative that I see would be way more complex
 and would be something like making the plugin read the .grf file format
 which allows specifying complex graphs.  Also I would need to make our app
 able to write these files which it doesn't currently.  Very much overkill in
 my opinion.
 
 The third alternative would be for me to expose DirectshowTexture but not to
 have commits accepted back to the community.
 
 Thoughts?
 
 Thanks
 -Brad
 
 -Original Message-
 From: osg-users-boun...@lists.openscenegraph.org
 [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
 Osfield
 Sent: Tuesday, June 29, 2010 3:28 AM
 To: OpenSceneGraph Users
 Subject: Re: [osg-users] Plugin to Node Kit?
 
 Hi Brad,
 
 The plugins are designed to be entirely encapsulated within themselves
 and not to export any symbols, save for any C function entry points
 for enabling static linking of plugins.  This decoupled approach does
 mean that you don't have any public interface to access internals
 classes/methods.  In general this isn't an issue though.
 
 What specifically about the DirectShowTexture header do you need
 access to?  It may be that you do what you want within any specific
 access to it.  Keeping a loose coupling is generally the best
 programming approach as it enables you to change you backend
 implementation easily - such as if you needed to support a new
 platform.
 
 Robert.
 
 On Tue, Jun 29, 2010 at 12:51 AM, Brad Huber br...@procerusuav.com wrote:
 Hello,



 I am curious what the path is for a osg plugin to become a node kit (or
 portions of it).  Does anyone have some information / insight?



 The reason that I ask is that I’m trying to use the Directshow texture
 class
 that is currently in the osg directshow plugin.  I do not believe a plugin
 is sufficient for what I’m trying to do because I want to work directly
 with
 the low-level directshow graph. As I understand, this is something that
 cannot be easily done via the file based plugin architecture.  For example
 I
 want to instantiate a rather complex graph (programmatically from a GUI)
 and
 then connect a pin to the Directshow texture.



 Perhaps I’m not seeing the correct way to go about this, if so, I would
 love
 some advice.  Otherwise- what is the process to go from plugin to node kit
 especially for a platform specific library such as directshow.



 Thanks for your input



 -Brad

 ___
 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] Plugin to Node Kit?

2010-06-29 Thread Brad Huber
Stephan,

Excellent idea.  I'm still cutting my teeth on this stuff.  I'll pursue this
option.  I'll see if I can find some examples of passing non-primitive types
through the plugin options.

Thanks
-Brad

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Stephan
Maximilian Huber
Sent: Tuesday, June 29, 2010 10:27 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Plugin to Node Kit?

Hi Brad,

if the only thing you want is to pass paramters / objects to the plugin,
so it sets up its stuff accordingly you can use
ReaderWriter::Options::setPluginData and extend the DirectoShow-Plugin
to use these plugin-data if available.

So you can feed you directshow-pin to the plugin and set it up
accordingly and you can submit these changes back to the community.

This should work the other way round, too. Add the data you are
interested in to the options-object, and use them afterwards.

Just thinking loud,

cheers,
Stephan



Am 29.06.10 17:57, schrieb Brad Huber:
 Robert,
 
 Here is what I would like to do:
 
 We have an existing app that has a GUI which builds a directshow graph
 including selecting a capture device and properties on that capture device
 and building the necessary intermediate filters.  If I can pass a
Directshow
 Pin (or pointer to pin) into the directshow texture then my work is done.
 Obviously this does require the tighter coupling of which you speak.
 
 Within the plugin architecture- the current abilities of osgDirectshow are
 not expressive enough.  The alternative that I see would be way more
complex
 and would be something like making the plugin read the .grf file format
 which allows specifying complex graphs.  Also I would need to make our app
 able to write these files which it doesn't currently.  Very much overkill
in
 my opinion.
 
 The third alternative would be for me to expose DirectshowTexture but not
to
 have commits accepted back to the community.
 
 Thoughts?
 
 Thanks
 -Brad
 
 -Original Message-
 From: osg-users-boun...@lists.openscenegraph.org
 [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
 Osfield
 Sent: Tuesday, June 29, 2010 3:28 AM
 To: OpenSceneGraph Users
 Subject: Re: [osg-users] Plugin to Node Kit?
 
 Hi Brad,
 
 The plugins are designed to be entirely encapsulated within themselves
 and not to export any symbols, save for any C function entry points
 for enabling static linking of plugins.  This decoupled approach does
 mean that you don't have any public interface to access internals
 classes/methods.  In general this isn't an issue though.
 
 What specifically about the DirectShowTexture header do you need
 access to?  It may be that you do what you want within any specific
 access to it.  Keeping a loose coupling is generally the best
 programming approach as it enables you to change you backend
 implementation easily - such as if you needed to support a new
 platform.
 
 Robert.
 
 On Tue, Jun 29, 2010 at 12:51 AM, Brad Huber br...@procerusuav.com
wrote:
 Hello,



 I am curious what the path is for a osg plugin to become a node kit (or
 portions of it).  Does anyone have some information / insight?



 The reason that I ask is that I'm trying to use the Directshow texture
 class
 that is currently in the osg directshow plugin.  I do not believe a
plugin
 is sufficient for what I'm trying to do because I want to work directly
 with
 the low-level directshow graph. As I understand, this is something that
 cannot be easily done via the file based plugin architecture.  For
example
 I
 want to instantiate a rather complex graph (programmatically from a GUI)
 and
 then connect a pin to the Directshow texture.



 Perhaps I'm not seeing the correct way to go about this, if so, I would
 love
 some advice.  Otherwise- what is the process to go from plugin to node
kit
 especially for a platform specific library such as directshow.



 Thanks for your input



 -Brad

 ___
 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

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


Re: [osg-users] Shader composition, OpenGL modes and custom modes

2010-06-29 Thread Bruce Wheaton
 
Very excited about the new features Robert, sounds like you're really cracking 
on.

I had two thoughts I hope you'll consider integrating:

One is that GLSL is quite poor for initialization. The main problem with this 
is if you were to enable a shader with, say, 8 uniforms, there wasn't, until 
very recently, a way to initialize them, and the stateset enable calls 
generally are single parameter. So in with the definitions of a new possible 
shader mode, and the attributes/uniforms it needs, we will probably need a way 
to initialize any uniforms that the shader needs, but the user may not 
specifically set. Default values, in essence, but also just non-random values.

Second is that, although your point about trying linking on the fly and then 
seeing what happens is a good one, I'm worried about the fact that different 
GPUs, drivers, OS's etc have very different costs for this, (all of which would 
be too much in some circumstances).

I was thinking that we could maybe build in the ability to use a conditional in 
each shader as a matter of course. That way the program object can be left as 
is, and sorted correctly, and the conditional uniform set instead of 
re-linking. The comparable mechanism to me is the 'dynamic' setting of nodes, 
or the 'useDisplayLists' setting.

So for example, instead of just:

vec4 applyBlur (vec4 inPixel
{
return inPixel;
}

or 

vec4 applyBlur (vec4 inPixel)
{
 vec4 outPixel;
// do costly blur
return outPixel;
}

the non-placeholder version might have:

vec4 applyBlur (vec4 inPixel)
{
if (!blurEnabled)
return inPixel;

 vec4 outPixel;
// do costly blur
return outPixel;
}

I hope you see the advantages - far more shader sharing and less compilation in 
a complex situation.

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


[osg-users] Load of 8 bits image for creating texture

2010-06-29 Thread Adrien Chassard
Hi,

I try to load a 8bits image and create an osg::Texture2D with it. I search all 
the day but without sucess. 

It seems that the image load by osgDB::readImageFile(...) is transform in a 32 
bits image. Is it possible to load it as 8bits image with an associated look up 
table ? (I didn't find attribut in osg::Image that could correspond to a lut, 
is there one ?)

However if I can load my image as a 8 bits image, I don't know how I can 
associate the color table to the texture, is there a way to do that ?

In fact and to clarify what I mean, here is the code in OpenGL I would like to 
translate in OpenSceneGraph :

glColorTableEXT(GL_TEXTURE_2D, GL_RGBA8, 256, GL_RGBA, GL_UNSIGNED_BYTE, 
colorTable);
glTexImage2D(GL_TEXTURE_2D, 0, GL_COLOR_INDEX8_EXT, width, height, 0, 
GL_COLOR_INDEX, GL_UNSIGNED_BYTE, texture);

I hope I was enough clear. Sorry if I wasn't.

Thank you very much for your help.

Cheers,
Adrien

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





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


[osg-users] Graphical issues with display lists on ATI 5870 cards

2010-06-29 Thread Andy Peruggi
Hi everyone,

My company has been developing products using OSG for a few years now, and 
recently we've noticed some rendering issues on two machines that are both 
running ATI 5870 cards using the latest ATI drivers (Catalyst 10.6). We wanted 
to know if anyone running similar hardware has seen these issues. We are using 
the 2.8.2 release of OSG.

We notice two major graphical problems:
* Incorrect lighting on primitives - flat geometry with equal vertex normals at 
all vertices appears to have incorrect lighting over the surface (using the 
default osgviewer lighting)
* Corrupted textures - either a single pixel color over the entire surface or 
it looks like the UV coordinates were run through a blender

We have tested rendering using the OSGViewer with a simple .osg file containing 
two triangles (forming a quad) with identical per-vertex normals and simple 
per-vertex UVs. What we have found is that we either have to disable display 
lists on the geometry in order to have the quad render correctly, or else we 
seem to be able to get correct results by adding additional (bogus) values to 
the per-vertex normal and UV lists to pad them. We believe this means that 
somewhere between OSG and the GPU the per-vertex data in the display list is 
getting corrupted and normals/UVs are getting lost.

We have not experienced this issue in any other 3D apps on this hardware, 
including ones that use display lists. We also do not have the rendering issues 
with our app on other hardware (tested using several nVidia cards and and older 
ATI card). We think this may be an ATI driver bug, but we're not sure at this 
point and would like to hear if anyone else has run into these issues.

Thanks.

- Andy Peruggi
Applied Research Associates, Inc[/list]

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





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


Re: [osg-users] Shader composition, OpenGL modes and custom modes

2010-06-29 Thread Roland Smeenk
Hi Robert and others,

unfortunately I am experiencing some stressfull time at work which does not 
really allow me to contribute to this thread as much as I would like to. I am 
trying to keep up with the posts, but not all posts are clear to me.


robertosfield wrote:
 
 1) Provide a way of encapsulating all the details required to
 contribute a single chunk of functionality that will be combined with other 
 active ShaderSet to provide final composed osg::Program.
 


Isn't this what I solved with the ShaderMode class? 
Or is it that you are trying to separate the shader mode associated with a 
StateAttribute from the part that is responsible for adding of the piece of 
shader functionality. 


robertosfield wrote:
 
 2) Provide a convenient mapping of a single ShaderSet representing a single 
 implementation that can be shared by multiple osg::StateAttribute objects, 
 for instance all osg::Light objects would share a single
 ShaderSet for all directional lights, another ShaderSet for all positional 
 lights etc.  If different state attribute objects share the same ShaderSet 
 then there it will be easily to test whether shaders are the same simply be 
 testing the pointer value, we needn't look into the contents.
 


In my contribution I implemented a single ShaderMode that implements all fixed 
function lighting possibilities. For new types of lighting it seems more 
logical to indeed make a more fine grained breakup of ShaderModes.

However there's a (minor) advantage to this one size fits all lighting code 
currently.  To enable or disable lighting you simply can override a single 
mode. In the case where there are multiple lighting modes (directional, spot 
etc.) overall disabling of lighting needs to be done per lighting type. It 
might be needed that multiple ShaderSets implementing the same aspect/feature 
can be switched on or off all together with a single override. This will also 
be needed for instance in shadow map creation where in the first pass you would 
like to render geometry into a shadowmap as cheaply as possible and therefore 
without lighting.
Perhaps multiple ShaderSets implement a the same aspect/feature in the final 
program that need to be disabled or enabled collectively. Again in the case of 
shadowmap creation you would like to only render geometry, no texturing, no 
lighting, no fog, but you do want to take into account skinned mesh 
deformation, wind deflection etc.


robertosfield wrote:
 
 3) The ShaderSet would contain list osg::Shader objects, these osg::Shader 
 objects would target which ever part of the overall program that the 
 ShaderSet effects - be in multiple osg::Shader for vertex programs, one of 
 vertex program one for fragment, or any combination.  
 


I guess you are more targeting shader linking instead of the code generation 
that I implemented.


robertosfield wrote:
 
 The individual osg::Shader objects could also be shared by multiple ShaderSet 
 where appropriate.
 


It could, but is this likely to happen?


robertosfield wrote:
 
 5) It might well be that some StateAttribute have unifoms but no ShaderSet,
 


I see no logical use case for this. What need is a uniform if there's no 
ShaderSet using it?


robertosfield wrote:
 
  it might also be appropriate for some StateAttribute to have no uniforms and 
 a ShaderSet.  
 


Like the normalize in the fixed function pipeline?


robertosfield wrote:
 
 It might even be appropriate for a single
 StateAttribute to have multiple ShaderSet depending upon what mode it is in - 
 for instance osg::Light might be implemented in such a way that you have one 
 ShaderSet for a directional light, and one ShaderSet for position light, 
 another for spot lights, another for per pixel lighting etc, and select the 
 appropriate one depending upon the set up of the osg::Light.
 


OK, understandable if you are targetting shader linking and taking into account 
what I wrote above.

Some other notes:

Like I discussed before I still would like to emphasize the need to be able to 
tune performance by balancing between shader program size and number of program 
switches. There is no optimal solution before knowing the actual usage scenario 
and therefore a user or internal OSG balancing system should be able to adapt 
this balance to improve rendering performance.

A thing not solved in my ShaderModes based implementation is support for CPU 
side calculations needed by the simulation or renderer. This includes 
intersection testing and bounding box calculation. When implementing a new 
piece of shader functionality (for instance wind deflection) is typically is 
not hard to implement the same on the CPU side. If there exists a mechanism to 
make the intersection visitor walk through the same ShaderMode tree (or linked 
ShaderSets) it could made be possible to actually intersect a tree swaying in 
the wind.

To clearify the aspect/feature override part mentioned above here's a different 
use case I have in mind. In a 

[osg-users] Understanding Transparent Textures with an transparent image with alpha channels

2010-06-29 Thread Tim Larson
I am attempting to utilize a transparent image as a texture map.

I can successfully display the transparent image as a texture on a simple 
rectangular geometry.

But, I would like to be able to see through to the background wherever the 
image is transparent.

I've utilized the osgHelp program GeometryTexture as a baseline and I can 
load my image, but the transparent parts of the image show through to the 
default gray material of the underlying geometry.  I see a gray rectangle with 
my image on top of it.  Even though my image has many transparent areas.

I would like to be able to see through the transparent areas of the image into 
the background.  i.e. If all I have on the screen is a single rectangular 
geometry with my transparent image, then I'd like to see the blue background 
through the transparent parts of my image.

Can anyone give me a pointer or advise?

Thanks in Advance.

Tim

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





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


Re: [osg-users] Graphical issues with display lists on ATI 5870 cards

2010-06-29 Thread Wojciech Lewandowski

Hi Andy,

I have seen some funky effects recently on Radeon 5970  4890.   I was not 
able to install 10.6 on Windows 7 64 bit on 5970. Driver kept crashing with 
classic BSOD. But texture corruption you mention was present in 10.5 on 
Radeon 4890 as well. In both cases we switched back to Catalyst 10.4. We 
have read on the forums that ATI started to experiment with GL 3.3  4.0 
recently and broke OpenGL 2.0 compatibility in latest drivers.


My other observations on Catalyst 10.4 are related to Texture Matrix default 
not being identity in the shaders. Light attenuation factors seem to be 
incorrect in shaders as well. Frankly I don't have  much experience with 
testing on Radeons, I ony have recently made few experiments. I could not 
count them as successful. Good thing about Windows 7 is one can have both 
NVidia  ATI installed together. Card that displays main screen renders all 
OpenGL so usually after some frustrating tests on ATI, I quickly switch main 
monitor to NVidia ;-).


Cheers,
Wojtek

--
From: Andy Peruggi aperu...@ara.com
Sent: Tuesday, June 29, 2010 8:02 PM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Graphical issues with display lists on ATI 5870 cards


Hi everyone,

My company has been developing products using OSG for a few years now, and 
recently we've noticed some rendering issues on two machines that are both 
running ATI 5870 cards using the latest ATI drivers (Catalyst 10.6). We 
wanted to know if anyone running similar hardware has seen these issues. 
We are using the 2.8.2 release of OSG.


We notice two major graphical problems:
* Incorrect lighting on primitives - flat geometry with equal vertex 
normals at all vertices appears to have incorrect lighting over the 
surface (using the default osgviewer lighting)
* Corrupted textures - either a single pixel color over the entire surface 
or it looks like the UV coordinates were run through a blender


We have tested rendering using the OSGViewer with a simple .osg file 
containing two triangles (forming a quad) with identical per-vertex 
normals and simple per-vertex UVs. What we have found is that we either 
have to disable display lists on the geometry in order to have the quad 
render correctly, or else we seem to be able to get correct results by 
adding additional (bogus) values to the per-vertex normal and UV lists to 
pad them. We believe this means that somewhere between OSG and the GPU the 
per-vertex data in the display list is getting corrupted and normals/UVs 
are getting lost.


We have not experienced this issue in any other 3D apps on this hardware, 
including ones that use display lists. We also do not have the rendering 
issues with our app on other hardware (tested using several nVidia cards 
and and older ATI card). We think this may be an ATI driver bug, but we're 
not sure at this point and would like to hear if anyone else has run into 
these issues.


Thanks.

- Andy Peruggi
Applied Research Associates, Inc[/list]

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





___
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] moving object along rotated vector

2010-06-29 Thread Sanat Talmaki
Hi,

I am attaching a screenshot of what I am trying to do. In the screenshot you 
can see 2 objects placed on a terrain. The lower one is rotated about Z axis 
and I use the keyboard UP and DOWN keys to move the object along the Y-axis in 
the terrain.

However even after I have rotated the object, I am not able to figure out how 
to get the new vector along which the object is now pointing. 

I figured I would find the angle I have rotated the object by using Quat and 
then depending on angle value 0-90, 90-180, 180-270 or 270-360, find the 
tangent of the angle and move it that way. But I'm sure im complicating things 
here.

The code I'm using to move the object and rotate is pasted below: (i've only 
copied the cases for Up and rotate right as down and left are identical)

else if ( ea.getKey()==osgGA::GUIEventAdapter::KEY_Up)
{
std::cout  textBox-getText()  std::endl;   

positionArray = PATCurrent-getPosition();
//vector = PATCurrent-getAttitude().asVec3();
PATCurrent-getAttitude().getRotate(angle,vector);
angleDegrees = osg::RadiansToDegrees(angle);
y = positionArray.y();
x = positionArray.x();
x += vector.x();
y += 1;
positionArray.y()=y;
positionArray.x()=x;
PATCurrent-setPosition(positionArray);
return true;
} 
else if ( ea.getKey()==osgGA::GUIEventAdapter::KEY_Right)
{
//use key right to rotate the object to the right
quat = PATCurrent-getAttitude();
quat.getRotate(angle, vector);
angleDegrees = osg::RadiansToDegrees(angle);
//if angle is 0 make it 360
if(angleDegrees = 1)
{
  angleDegrees = 360;
}
angleDegrees -= 1;

quat.makeRotate(osg::DegreesToRadians(angleDegrees),vector);
PATCurrent-setAttitude(quat);
//PATCurrent-setPosition(vector);
}

If you can tell me what I am missing out here I'd be very thankful.

Also, if there is some literature out there that deals with this, I'd be more 
than happy to study it.

Thanks,

Sincerely,

Sanat

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




Attachments: 
http://forum.openscenegraph.org//files/test_sc1_368.jpg


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