date:20090806

Hi,
I have a model in ive format and osgviewer displays it fine. However if i 
convert it to osg, i get black and white shaded files as textures, which are of 
no use. I am using osgconv.exe with the following command line 

osgconv.exe -e osg -O OutputTextureFiles -O precision:0.001 model.ive model.osg

Is there anything which i am missing ??

Thank you!
Mach

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





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

Re: [osg-users] OSG and shaders

2009-08-06 Thread Hadrien Thomas

Thank you for the book reference. I will think about purchasing it. I can 
afford it but it's a big expense for me  :-* 

For now, I'm still blocked with OSG.
I want to map the same texture to the 6 faces of a cube.

I made a Geometry called cube and 6 DrawElementsUInt called face1/2/.../6.

I don't know how to setTexCoords to each QUADS.
I thought about making 6 Geometry so I can use a same vertice several times but 
I don't find any method able to link them into a cube as a single geometry.

Is there any other solution? Maybe I can do it with shaders but with so few 
experience I can't see the possibilities they bring.

Thanks again for your help :)

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





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

Re: [osg-users] OSG and shaders

2009-08-06 Thread Kim Bale

I agree with Paul, the Orange book is a *must have* title if you're
learning shaders.

http://books.google.co.uk/books?id=kDXOXv_GeswCdq=opengl+shader+languageprintsec=frontcoversource=bnhl=enei=E5Z6Svb-K5Cy-AbQ87lSsa=Xoi=book_resultct=resultresnum=5#v=onepageq=opengl%20shader%20languagef=false

2009/8/5 Paul Speed psp...@progeeks.com:
And it deserves saying, if you can get your hands on an OpenGL Orange Book
you'll be that many more steps ahead. I thought it was really good at
explaining things in depth while also being easily navigated to drill in on
target areas.

I had complex shaders up and running in a few days with that book... I have
had some embedded-style coding experience before, though.

-Paul

Maxime BOUCHER wrote:

Well,

I'm doing an internship too.

At the beginning I didn't know osg at all, neither shaders.
There are still an extraordinary amount of things I ignore about OSG (my
advice: when you try to do or understand something, take a look at how it's
done in OpenGL).
Shaders aren't as hard to use as OSG, I discovered about one month ago and
I can now write some modests but nice effects.

The essential is to read code and tutorials.
Don't try to go fast, it's the best way to misunderstand what you
manipulate and to write bad code, failing your internship. You have 6
months, you can waste it OR spend 2 months to understand osg and shaders and
then writting good code, masterizing your internship.

Thus, first read a few osg tutorials (to understand how textures are
mapped for example, it seems you don't), I think the 4 or 5 firsts should be
enough.
After, try to understand what is a shader (I guess you don't really).
Then try to understand the shader tutorials from typhoonlabs, or this
(http://www.siteduzero.com/tutoriel-3-8879-communiquer-avec-l-application-attributs-et-uniforms.html?bcsi-ac-20A76BC15DBD50F6=194870AE0303lbVE9ryZWUuZzrBgMzY7DS6IPWi9BwMAAMDCRwEQDgAAINVbBwA=),
it's in french.
I advice to look at osgshader example ONLY to understand (or copy the
code) how to load and activate a shader, it's 5 lines.

Don't take me for moralistic, I did these errors.

Good luck and take your time, it's the best way to success.

Cheers,
Maxime

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

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

Re: [osg-users] Computing depth buffer in osgVolume

Hi Yvon,

The present osgVolume shaders that I've written compute the ray start
position from the initial fragment generated by rendered the backface
of the cube, then shoots the ray forward towards the eye point and
then clamps this to the dimensions of the cube.  It then computes the
texcoords for this from these ray coords.

Robert.

On Wed, Aug 5, 2009 at 7:40 PM, Yvon Halbwachsy...@kalkulo.no wrote:
 Hi,

 I would like to add the computation of the z-depth value in the ray traced
 volume shaders. I'm pretty new to raytracing on gpu, so forgive me if this
 is a naive question!

 I've tried to add this code in the fragment shader, just after the line
 gl_FragColor = color:

      
      gl_FragColor = color;

      vec4 inter = gl_ModelViewProjectionMatrix * vec4(texcoord,1);
      gl_FragDepth = inter.z / inter.w;

      return;
      In theory my idea is to compute the position of the intersection with
 the volume, and use the model view  projection transformation matrix to get
 z buffer value computed. It looks good... but it's not right!

 Does any one have an idea about what I'm doing wrong?

 Thanks for any help,

 Regards,

 Yvon

 ___
 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] Importance Of Node Path List In Database Pager

Hi Ryan,

On Wed, Aug 5, 2009 at 10:36 PM, Kawicki, Ryan
Hryan.h.kawi...@boeing.com wrote:
 I was just curious to see if anything was committed to the 2.9.x / 2.10 
 baselines for this.  I know that you stated that you already had code in 
 place to fix this issue.  Thanks.

I thought I had code in place, but when I reviewed the code it wasn't
there, so my guess is that I probably didn't write it but thought
about it and implemented something simpler to address the particular
problem in hand.  There is no RefNodePath recorded by
DatabasePager::DatabaseRequest right now, so we still have to write
this.

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

Re: [osg-users] OSG and shaders

2009-08-06 Thread Maxime BOUCHER

Hi,


carnibirdy wrote:
 
 For now, I'm still blocked with OSG.
 I want to map the same texture to the 6 faces of a cube.
 
 I made a Geometry called cube and 6 DrawElementsUInt called face1/2/.../6.
 
 I don't know how to setTexCoords to each QUADS.
 I thought about making 6 Geometry so I can use a same vertice several times 
 but I can't find any method able to link them into a cube as a single 
 geometry.
 
 Is there any other solution? 
 

Look at this:
http://faculty.nps.edu/jasullivan/osgtutorials/


carnibirdy wrote:
 
 Maybe I can do it with shaders but with so few experience I can't see the 
 possibilities they bring.
 

It depends on what you want to do.
It seems to me you don't want to do it this way.


Cheers,

Max

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





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

Re: [osg-users] Deadlock when loading osg.dll, singletons are evil


Hi Robert,

You do have to understand that what is currently happening is an
implicit init/destroyOsg through DllMain. The problem is that DllMain is
full of limitations. Only a handful of kernel functions can be safely
called in DllMain. Worse, Microsoft in all their wisdom does not provide
the list of safe functions.

According to DllMain documentation on MSDN, and due to the fact that
it's an implementation detail, calling any C standard functions in
DllMain is undefined behaviour. Our particular scenario is just one
possible way things can go wrong. MSDN documentation states that an
access violation error is also possible.


I've been thinking last night to try finding a solution to the problem
that is less intrusive on the API than an explicit init/destroyOsg. I
was thinking of using a lazy initialisation on any singleton that
makes a C function call. For example:

static const char * env = getenv(OSG_GL_EXTENSION_DISABLE);

could be replaced by

static Mutex s_mutex;

const char * getSingletonGlExtensionDisable()
{
ScopedLock lock(s_mutex);

static const char * env = getenv(OSG_GL_EXTENSION_DISABLE);

return env;
}


Such a solution guarantees that no C functions is called in DllMain
during DLL loading (note that the Mutex construction is guaranteed to be
safe by MSDN doc). Although, destruction of the singletons still occurs
in DllMain, so it should be checked that the singleton destructors do
not call any C functions.

I'm aware that such a solution does have a performance impact because of
the mutex (the mutex is mandatory to guarantee thread safety). However,
if an object needs to often access a singleton, it can cache the
returned pointer (once an object's got the singleton, it is safe to use
the returned pointer without having to call getSingleton() again and
again, except of course when DllMain is called to unload the DLL).

It's not a perfect solution, but I think it's better than the current
undefined behaviour. What do you think?

Regards,

Tanguy


-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: 05 August 2009 13:26
To: OpenSceneGraph Users
Subject: Re: [osg-users] Deadlock when loading osg.dll, singletons are
evil

Hi Tanguy,

On Wed, Aug 5, 2009 at 12:55 PM, Tanguy
Fautretang...@aristechnologies.com wrote:
 To come back to the deadlock issue, I don't think there is any way to
fix it without breaking the current OSG API compatibility. While I would
favour removing the singletons (and would heavily suggest other designs
for OSG 3.0), I perfectly understand and agree with you that such an
approach is unacceptable in the short term.

Um... I have yet to see a compelling reason for not using singletons
like Registry or a decent proposal for a replacement.   For OSG-3.0 my
plan is to focus on refactoring just the core scene graph and how
rendering is implemented, for the rest of the API changes we should
keep as minimal as possible to try and reduce to headache of porting
from OSG-2.x to OSG-3.x.  We can't avoid refactoring the core scene
graph state management to be able to do shader composition, but the
rest of changes we minimize.

 The least disruptive solution I can think of (while being quite
robust) would be to introduce an initOsg() and a destroyOsg() function.
It's a fairly common approach and is in fact the one mandated by MSDN
regarding the limitations of DllMain (and the deadlocks that may follow
if violated).

My gut reaction is YUK.   Design wise, implementation wise and support
wise I know it's a hack.


 initOsg() would initialize and construct all the global variables of
Osg when called, while destroyOsg() would take care of the destruction
of such objects.

OK. So this uber initOsg() method would need to initialize all global
variables and hence know about all global variance and hence be
tightly coupled with all global variables.  Now if you have a very
simply set of libs to work with, and everything is fixed in it's
relationship this might work, but... if you have a loosely coupled
design that allows you to extend it at runtime what then??  For
instance NodeKits... who inits these?   Do we have explict init's for
each NodeKit the user might use.  What about NodeKits that are pulled
in at runtime to enable the loading of a particular databases?


 The benefits are twofold:
 - The user would have a better control on the lifetime of the OSG and
its global variables (among other things, solving the deadlock issue
exposed in this discussion).
 - The user would have the ability to reset the library in a
predictable manner, which is currently impossible.

 A few points should be observed:
 1. init/destroyOsg needs to be referenced counted (allowing multiple
and re-entrant initializations)
 2. init/destroyOsg needs to be thread-safe
 3. init/destroyOsg needs to be aware that osg is divided into several
components (e.g. osg, osgDB, osgViewer, etc). It would

Re: [osg-users] Deadlock when loading osg.dll, singletons are evil

2009-08-06 Thread Daniel Trstenjak


Hi Tanguy,

 static Mutex s_mutex;
 
 const char * getSingletonGlExtensionDisable()
 {
 ScopedLock lock(s_mutex);
 
 static const char * env = getenv(OSG_GL_EXTENSION_DISABLE);
 
 return env;
 }

This doesn't make sense, because 'getenv' is called only once, during
the initialization of the static variable 'env'. After that the
value of 'env' doesn't change, but for every call to
'getSingletonGlExtensionDisable' a lock is used.

If the value of 'OSG_GL_EXTENSION_DISABLE' shouldn't change during
runtime:

static Mutex s_mutex;

const char* getSingletonGlExtensionDisable()
{
   static char* env = 0L;
   if (env == 0L) {
  ScopedLock lock(s_mutex);
  env = getenv(OSG_GL_EXTENSION_DISABLE);
   }

   return env;
}




Greetings,
Daniel


-- 

   
 Daniel Trstenjak Tel   : +49 (0)7071-9457-264
 science + computing ag   FAX   : +49 (0)7071-9457-511
 Hagellocher Weg 73   mailto: daniel.trsten...@science-computing.de
 D-72070 Tübingen WWW   : http://www.science-computing.de/  

-- 
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

Re: [osg-users] Deadlock when loading osg.dll, singletons are evil

Hi Daniel,

Your proposed solution looks like a variant of the Double Checked Locking. 
Unfortunately, this design pattern is very subtly broken and not thread safe. 
See http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf for more 
information.

I've however shown this example just to illustrate a more general problem, as 
most of the getenv() are (in)directly called from within class constructors. 
Hence, what we're looking as is something more similar to the following.

static Mutex s_mutex;

Object  getSingletonObject()
{
ScopedLock lock(s_mutex);

static Object object;

return object;
}


Cheers,

Tanguy


-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Daniel 
Trstenjak
Sent: 06 August 2009 12:24
To: OpenSceneGraph Users
Subject: Re: [osg-users] Deadlock when loading osg.dll, singletons are evil


Hi Tanguy,

 static Mutex s_mutex;
 
 const char * getSingletonGlExtensionDisable()
 {
 ScopedLock lock(s_mutex);
 
 static const char * env = getenv(OSG_GL_EXTENSION_DISABLE);
 
 return env;
 }

This doesn't make sense, because 'getenv' is called only once, during
the initialization of the static variable 'env'. After that the
value of 'env' doesn't change, but for every call to
'getSingletonGlExtensionDisable' a lock is used.

If the value of 'OSG_GL_EXTENSION_DISABLE' shouldn't change during
runtime:

static Mutex s_mutex;

const char* getSingletonGlExtensionDisable()
{
   static char* env = 0L;
   if (env == 0L) {
  ScopedLock lock(s_mutex);
  env = getenv(OSG_GL_EXTENSION_DISABLE);
   }

   return env;
}




Greetings,
Daniel


-- 

   
 Daniel Trstenjak Tel   : +49 (0)7071-9457-264
 science + computing ag   FAX   : +49 (0)7071-9457-511
 Hagellocher Weg 73   mailto: daniel.trsten...@science-computing.de
 D-72070 Tübingen WWW   : http://www.science-computing.de/  

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

Re: [osg-users] Deadlock when loading osg.dll, singletons are evil

Hi Tanguy,

I was wondering about the possibility of wrapping up the access to the
sensitive C functions using a Mutex.  We couldn't do it in local code,
but would need to do it via a single custom getenv() etc. function
implementation, otherwise we'd still end up with multiple functions
potentially accessing standard C functions like getenv in a parallel.

Like Daniel's suggestion of moving the Mutex into the getenv init
avoiding the overuse of the locking the mutex, doing the lock in
central function would also achieve this aim.

So perhaps we co do something like:

static Mutex s_mutex;

const char* serialized_getenv(const char* str)
{
ScopedLock lock(s_mutex);
return getenv(str);
}

void* serialized_otherSensitiveCFunction(...)
{
   ScopedLock lock(s_mutex);
   return otherSensitiveCFunction(...);
 }

Then all the init code would call these methods.  Note the
implementations would all be in the .cpp's.

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

Re: [osg-users] Deadlock when loading osg.dll, singletons are evil

Hi Robert,

Unfortunately serializing the access to getenv() is not likely to solve
the issue. The problem is not that OSG calls several getenv() in
parallel, the problem is that getenv() should not be called *at all* in
DllMain().

Serializing getenv() in OSG does not guarantee that another C function
will not be called in another thread unrelated to OSG. In fact, this is
exactly what is happening to us.

Wrt to Daniel's suggestion, it's a variant of the double checked
locking, which is unfortunately subtly broken (cf. previous post).


Regards,

Tanguy


-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: 06 August 2009 12:48
To: OpenSceneGraph Users
Subject: Re: [osg-users] Deadlock when loading osg.dll, singletons are
evil

Hi Tanguy,

I was wondering about the possibility of wrapping up the access to the
sensitive C functions using a Mutex.  We couldn't do it in local code,
but would need to do it via a single custom getenv() etc. function
implementation, otherwise we'd still end up with multiple functions
potentially accessing standard C functions like getenv in a parallel.

Like Daniel's suggestion of moving the Mutex into the getenv init
avoiding the overuse of the locking the mutex, doing the lock in
central function would also achieve this aim.

So perhaps we co do something like:

static Mutex s_mutex;

const char* serialized_getenv(const char* str)
{
ScopedLock lock(s_mutex);
return getenv(str);
}

void* serialized_otherSensitiveCFunction(...)
{
   ScopedLock lock(s_mutex);
   return otherSensitiveCFunction(...);
 }

Then all the init code would call these methods.  Note the
implementations would all be in the .cpp's.

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

Re: [osg-users] osgconv.exe textures getting mangled


On Thu, 06 Aug 2009 10:31:57 +0200, Mach Bhai sar...@dsi.co.ae wrote:


Hi,
I have a model in ive format and osgviewer displays it fine. However if  
i convert it to osg, i get black and white shaded files as textures,  
which are of no use. I am using osgconv.exe with the following command  
line


osgconv.exe -e osg -O OutputTextureFiles -O precision:0.001 model.ive  
model.osg


Try

osgconv.exe -e osg -O OutputTextureFiles precision 4 model.ive model.osg

precision takes an integer
multiple options are space separated

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

Re: [osg-users] Deadlock when loading osg.dll, singletons are evil

2009-08-06 Thread Daniel Trstenjak


Hi Tanguy,

 Your proposed solution looks like a variant of the Double Checked
 Locking. Unfortunately, this design pattern is very subtly broken and
 not thread safe. See
 http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf for more
 information.

It depends what you want to make thread safe. If the call to
'getSingletonGlExtensionDisable' should be thread safe, than
you're right. If it's enough to make the call to 'getenv'
thread safe, than the solution should be alright.
 

Greetings,
Daniel

-- 

   
 Daniel Trstenjak Tel   : +49 (0)7071-9457-264
 science + computing ag   FAX   : +49 (0)7071-9457-511
 Hagellocher Weg 73   mailto: daniel.trsten...@science-computing.de
 D-72070 Tübingen WWW   : http://www.science-computing.de/  

-- 
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

Re: [osg-users] osgconv.exe textures getting mangled

Thanks but it didnt work. I am still not getting correct textures.

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





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

Re: [osg-users] Deadlock when loading osg.dll, singletons are evil

Hi Tanguy,

On Thu, Aug 6, 2009 at 12:53 PM, Tanguy
Fautretang...@aristechnologies.com wrote:
 Unfortunately serializing the access to getenv() is not likely to solve
 the issue. The problem is not that OSG calls several getenv() in
 parallel, the problem is that getenv() should not be called *at all* in
 DllMain().

 Serializing getenv() in OSG does not guarantee that another C function
 will not be called in another thread unrelated to OSG. In fact, this is
 exactly what is happening to us.

OK... but as yet I'm still not clear on why you suggestion avoids the
init.  Is it simple that static's in the global scope are getting
initialized automatically, while ones inside methods are only
initialized on first call... So you've moved the static initializer
into the method...

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

Re: [osg-users] osgconv.exe textures getting mangled

On Thu, 06 Aug 2009 14:00:15 +0200, Joakim Simonsson joa...@autosim.no  
wrote:



On Thu, 06 Aug 2009 10:31:57 +0200, Mach Bhai sar...@dsi.co.ae wrote:


Hi,
I have a model in ive format and osgviewer displays it fine. However if  
i convert it to osg, i get black and white shaded files as textures,  
which are of no use. I am using osgconv.exe with the following command  
line


osgconv.exe -e osg -O OutputTextureFiles -O precision:0.001 model.ive  
model.osg


Try

osgconv.exe -e osg -O OutputTextureFiles precision 4 model.ive  
model.osg


precision takes an integer
multiple options are space separated


When I try the OutputTextureFiles option, I also get black and white  
striped textures.


What image format do you use? I use .rgb.

If you also use .rgb, perhaps it is something with the .rgb plugin...

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

Re: [osg-users] osgconv.exe textures getting mangled

Yes i am also getting rgb files. It might be that something is wrong with that 
plugin but i cannot verify. Can we specify the format of the texture ?

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





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

Re: [osg-users] osgconv.exe textures getting mangled


No, it is not possible.

The current osg implementation looks for the filename extension for the  
texture inside the .ive file.
If the texture originally was an .rgb texture, it will try to write it to  
that format as well.


On Thu, 06 Aug 2009 14:17:43 +0200, Mach Bhai sar...@dsi.co.ae wrote:

Yes i am also getting rgb files. It might be that something is wrong  
with that plugin but i cannot verify. Can we specify the format of the  
texture ?


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





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



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

Re: [osg-users] Deadlock when loading osg.dll, singletons are evil

Hi Robert,

As you said, doing (2)

const char * getSingletonGlExtensionDisable()
{
ScopedLock lock(s_mutex);
static const char * env = getenv(OSG_GL_EXTENSION_DISABLE);
return env;
}

instead of (1)

static const char * env = getenv(OSG_GL_EXTENSION_DISABLE);

Ensures that the singleton initialization occurs only when the function
getSingletonGlExtensionDisable is called.

The problem is that solution (1) implies that the initialization is done
in DllMain: when osg.dll is loaded, the singleton will be automatically
initialized, which leads to getenv() being called in DllMain.

Solution (2) delays the initialization until the function getSingleton()
is called. If there is no global singleton left (or more precisely, if
there is no global scoped variable initialization code calling
getSingleton()), then you have the guarantee that the singleton will
only be initialized when the user starts explicitly calling osg
functions/classes.

In other words, solution (2) guarantees that DllMain has long been
executed before any singleton initialization occurs. Which is exactly
want we want.

Regards,

Tanguy


-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: 06 August 2009 13:14
To: OpenSceneGraph Users
Subject: Re: [osg-users] Deadlock when loading osg.dll, singletons are
evil

Hi Tanguy,

On Thu, Aug 6, 2009 at 12:53 PM, Tanguy
Fautretang...@aristechnologies.com wrote:
 Unfortunately serializing the access to getenv() is not likely to
solve
 the issue. The problem is not that OSG calls several getenv() in
 parallel, the problem is that getenv() should not be called *at all*
in
 DllMain().

 Serializing getenv() in OSG does not guarantee that another C function
 will not be called in another thread unrelated to OSG. In fact, this
is
 exactly what is happening to us.

OK... but as yet I'm still not clear on why you suggestion avoids the
init.  Is it simple that static's in the global scope are getting
initialized automatically, while ones inside methods are only
initialized on first call... So you've moved the static initializer
into the method...

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

Re: [osg-users] Deadlock when loading osg.dll, singletons are evil

Hi Tanguy,

As a first step I've just moved the GLExtension.cpp code that does the
static getenv() into the  osg::getGLExtensionDisableString() method so
it now reads:

std::string osg::getGLExtensionDisableString()
{
static const char* envVar = getenv(OSG_GL_EXTENSION_DISABLE);
static std::string
s_GLExtensionDisableString(envVar?envVar:Nothing defined);

return s_GLExtensionDisableString;
}

This isn't yet thread safe, but since the problem in hand isn't
directly a threading one this should be at least a little step towards
helping solve the problem.  Modified file attached.

Could you try this modification out at your end to see if it is
appropriate step forward.  A quick search shows other places where
there is static getenv in the global scope so I don't expect this one
tweak to be a complete solution, but if it does look like a way
forward then we can start rolling the fix out more generally.

Cheers,
Robert.
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield 
 *
 * This library is open source and may be redistributed and/or modified under  
 * the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or 
 * (at your option) any later version.  The full license is in LICENSE file
 * included with this distribution, and on the openscenegraph.org website.
 * 
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the 
 * OpenSceneGraph Public License for more details.
*/
#include osg/GLExtensions
#include osg/GL
#include osg/GLU
#include osg/Notify
#include osg/Math
#include osg/buffered_value

#include stdlib.h
#include string.h
#include stdio.h
#include float.h

#include string
#include vector
#include set

#if defined(WIN32)
#include windows.h
#endif

typedef std::setstd::string  ExtensionSet;
static osg::buffered_objectExtensionSet s_glExtensionSetList;
static osg::buffered_objectstd::string s_glRendererList;
static osg::buffered_valueint s_glInitializedList;

static osg::buffered_objectExtensionSet s_gluExtensionSetList;
static osg::buffered_objectstd::string s_gluRendererList;
static osg::buffered_valueint s_gluInitializedList;

float osg::getGLVersionNumber()
{
// needs to be extended to do proper things with subversions like 1.5.1, etc.
char *versionstring   = (char*) glGetString( GL_VERSION );
if (!versionstring) return 0.0;

std::string vs( versionstring );
return( asciiToFloat( vs.substr( 0, vs.find(   ) ).c_str() ) );
}

bool osg::isExtensionInExtensionString(const char *extension, const char *extensionString)
{
const char *startOfWord = extensionString;
const char *endOfWord;
while ((endOfWord = strchr(startOfWord,' ')) != 0)
{
if (strncmp(extension, startOfWord, endOfWord - startOfWord) == 0)
return true;
startOfWord = endOfWord+1;
}
if (*startOfWord  strcmp(extension, startOfWord) == 0)
return true;
   
   return false;
}

bool osg::isGLExtensionSupported(unsigned int contextID, const char *extension)
{
return osg::isGLExtensionOrVersionSupported(contextID, extension, FLT_MAX);
}

bool osg::isGLExtensionOrVersionSupported(unsigned int contextID, const char *extension, float requiredGLVersion)
{
ExtensionSet extensionSet = s_glExtensionSetList[contextID];
std::string rendererString = s_glRendererList[contextID];

// first check to see if GL version number of recent enough.
bool result = requiredGLVersion = osg::getGLVersionNumber();

if (!result)
{
// if not already set up, initialize all the per graphic context values.
if (!s_glInitializedList[contextID])
{
s_glInitializedList[contextID] = 1;

// set up the renderer
const GLubyte* renderer = glGetString(GL_RENDERER);
rendererString = renderer ? (const char*)renderer : ;

// get the extension list from OpenGL.
const char* extensions = (const char*)glGetString(GL_EXTENSIONS);
if (extensions==NULL) return false;

// insert the ' ' delimiated extensions words into the extensionSet.
const char *startOfWord = extensions;
const char *endOfWord;
while ((endOfWord = strchr(startOfWord,' '))!=NULL)
{
extensionSet.insert(std::string(startOfWord,endOfWord));
startOfWord = endOfWord+1;
}
if (*startOfWord!=0) extensionSet.insert(std::string(startOfWord));

#if defined(WIN32)

// add WGL extensions to the list

typedef const char* WINAPI WGLGETEXTENSIONSSTRINGARB(HDC);
WGLGETEXTENSIONSSTRINGARB* wglGetExtensionsStringARB = 0;
setGLExtensionFuncPtr(wglGetExtensionsStringARB, wglGetExtensionsStringARB);

typedef const char* WINAPI WGLGETEXTENSIONSSTRINGEXT();

Re: [osg-users] osgconv.exe textures getting mangled

So how can this issue be resolved ?

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





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

Re: [osg-users] osgconv.exe textures getting mangled


You are using compressed textures in the ive file, right?

I figured out that the rgb plugin can't write compressed textures.

The only pixel formats that are supported are:


GLenum pixelFormat = img.getPixelFormat();

raw.sizeZ =
pixelFormat == GL_COLOR_INDEX? 1 :
pixelFormat == GL_RED? 1 :
pixelFormat == GL_GREEN? 1 :
pixelFormat == GL_BLUE? 1 :
pixelFormat == GL_ALPHA? 1 :
pixelFormat == GL_RGB? 3 :
pixelFormat == GL_BGR ? 3 :
pixelFormat == GL_RGBA? 4 :
pixelFormat == GL_BGRA? 4 :
pixelFormat == GL_LUMINANCE? 1 :
pixelFormat == GL_LUMINANCE_ALPHA ? 2 : 1;

When an compressed pixelformat (0x83f0) is encountered, it is treated as  
an unknown pixel format. And hence 1 is used for sizeZ...



On Thu, 06 Aug 2009 14:42:03 +0200, Mach Bhai sar...@dsi.co.ae wrote:


So how can this issue be resolved ?


The issue can be solved by extending the rgb plugin, so that it can write  
compressed textures.


OR

Don't compress your textures when you create the ive file...

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

[osg-users] Hello from New Orleans

2009-08-06 Thread Paul MARTZ

OSG BOF was a success. Attendance was light, 65 people, but overall  
conference attendance was down this year.  Traveling today, more later  
including photos.


Paul Martz
Skew Matrix Software
http://www.skew-matrix.com
+1 303 859 9466

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

Re: [osg-users] osgconv.exe textures getting mangled

I will want to go with the first approach and add support for writing 
compressed textures. 
So how can I go about uncompressing this data ? Any clues ?

and thanks for your help.

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





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

Re: [osg-users] Deadlock when loading osg.dll, singletons are evil

Hi Robert,

We've got a custom build of OSG where we've commented out all the unsafe
getenv (we do not use env variables in our application anyway).

I'm gonna give your patch a few runs. In theory, it should not deadlock
(considering all the other unsafe getenv are already commented out).


Cheers,

Tanguy


-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: 06 August 2009 13:28
To: OpenSceneGraph Users
Subject: Re: [osg-users] Deadlock when loading osg.dll, singletons are
evil

Hi Tanguy,

As a first step I've just moved the GLExtension.cpp code that does the
static getenv() into the  osg::getGLExtensionDisableString() method so
it now reads:

std::string osg::getGLExtensionDisableString()
{
static const char* envVar = getenv(OSG_GL_EXTENSION_DISABLE);
static std::string
s_GLExtensionDisableString(envVar?envVar:Nothing defined);

return s_GLExtensionDisableString;
}

This isn't yet thread safe, but since the problem in hand isn't directly
a threading one this should be at least a little step towards helping
solve the problem.  Modified file attached.

Could you try this modification out at your end to see if it is
appropriate step forward.  A quick search shows other places where there
is static getenv in the global scope so I don't expect this one tweak to
be a complete solution, but if it does look like a way forward then we
can start rolling the fix out more generally.

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

Re: [osg-users] osgconv.exe textures getting mangled


On Thu, 06 Aug 2009 14:55:12 +0200, Mach Bhai sar...@dsi.co.ae wrote:

I will want to go with the first approach and add support for writing  
compressed textures.

So how can I go about uncompressing this data ? Any clues ?


You have to write an S3TC uncompressor.

I have done this in a school project some years ago... If you want I can  
try to dig up that code.




and thanks for your help.



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

Re: [osg-users] osgconv.exe textures getting mangled

If you can do that, it would be very kind of you.

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





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

Re: [osg-users] osgconv.exe textures getting mangled


Gotta go now. See what I can do tomorrow.

On Thu, 06 Aug 2009 15:24:40 +0200, Mach Bhai sar...@dsi.co.ae wrote:


If you can do that, it would be very kind of you.


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

Re: [osg-users] osgconv.exe textures getting mangled

thanks i am looking forward to your help

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





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

Re: [osg-users] osgconv.exe textures getting mangled

Hi Mach,

The .dds plugin supports writing compressed textures, so changing the
extension of the images from .rgb to .dds would probably do the trick.

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

Re: [osg-users] osgconv.exe textures getting mangled

Thanks, i only have the ive files, i dont have the original texture files.

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





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

Re: [osg-users] osgconv.exe textures getting mangled