Re: [Opensg-users] OpenSG2.0 - Issues and Improvements

Michael Raab Thu, 07 Aug 2014 02:52:49 -0700

Hello Carsten,

>> 3.) OSGImage: Added simple hash calculation to be able to compare images
>> faster.

>+ this->_hashCode = seed;
>+ for(UInt32 i=0; i<_mfPixel.size(); ++i)
>+ {
>+ this->_hashCode =
>+ this->_hashCode * prime + (Int32)(&(_mfPixel[i]));
>+ }
>+
>+ this->_hashCode = seed;

>err, it looks to me like there's some typos in this [1] and I'm afraid
>as is this does not give me a warm fuzzy feeling...
>Is the caching of the hash value important for you (given that it gets
>invalidated by a change to _any_ field of the image)? Otherwise I would
>slightly prefer to not make this a member function (Image already has a
>hugely fat interface), but a free utility function. Also, using
>OSG::SizeT for the hash code would make this play more nicely with C++11
>std::hash, which uses std::size_t.

Probably I was sleeping while implementing that..

Hope the following is ok..

inline
OSG::SizeT Image::getHash()
{
   if(!this->_hashCodeValid)
   {
       // recalculate hash..
       OSG::SizeT seed = 173;
       OSG::SizeT prime = 37;

       this->_hashCode = seed;
       for(UInt32 i=0; i<_mfPixel.size(); ++i)
       {
           this->_hashCode = this->_hashCode * prime + _mfPixel[i];
       }
       this->_hashCodeValid = true;
   }

return this->_hashCode;
}

Caching the hash value along with the image would be a useful feature as at certain times we do material optimizations which include the necessity to compare images quickly.

Computing the hash values over and over would cause a slowdown...

Thanks,

Michael

Gesendet: Donnerstag, 07. August 2014 um 11:25 Uhr
Von: "Carsten Neumann" <carsten.p.neum...@gmail.com>
An: opensg-users@lists.sourceforge.net
Betreff: Re: [Opensg-users] OpenSG2.0 - Issues and Improvements

Hello Michael,

On 08/06/2014 10:22 AM, Michael Raab wrote:
> we have some problems, actually crashes, on client laptop that use Intel
> HD chips. The problems are linked to the usage of BlendChunk's and I
> think we have narrowed it down to the BlendEquation.
> It seems Intel HD chips and their drivers do not support GL_ARB_imaging
> extension, which is necessary for glBlendEquation. This problem arised
> with the switch from 1.8 to 2.0. I checked the BlendChunk implementation
> for differences and I've got a presumption what may be the problem. In
> 1.8 the BlendChunk uses ::hasExtension() to check for GL_ARB_imaging.
> 2.0 uses hasExtOrVersion(). So I guess that the GL version is large
> enough to get a true here even if the extension is not supported. What
> is the reason why this check was changed?

my guess would be because it is in the standard since GL version 1.4 or
thereabouts - not that that would be the first time Intel drivers
claiming some version/feature as supported and then happily ignore it ;)
Let me take a look at your follow up patch and see if we can get this to
work for both conforming and broken drivers.

> Furthermore I've improved some other things:
> 1.) TextureBuffer::processPreDeactivate(): Check if image is assigned to
> TextureObj, before accessing it..

fixed,

> 2.) OSGGeoSplitVertexArrayPumpGroup/OSGGeoVertexArrayPumpGroup: We had
> some Geometries that had at certain times no vertices. Calling
> glDrawArray with vertexCount 0 caused crashes on some graphics cards. I
> added a check here.

fixed,

> 3.) OSGImage: Added simple hash calculation to be able to compare images
> faster.

+ this->_hashCode = seed;
+ for(UInt32 i=0; i<_mfPixel.size(); ++i)
+ {
+ this->_hashCode =
+ this->_hashCode * prime + (Int32)(&(_mfPixel[i]));
+ }
+
+ this->_hashCode = seed;

err, it looks to me like there's some typos in this [1] and I'm afraid
as is this does not give me a warm fuzzy feeling...
Is the caching of the hash value important for you (given that it gets
invalidated by a change to _any_ field of the image)? Otherwise I would
slightly prefer to not make this a member function (Image already has a
hugely fat interface), but a free utility function. Also, using
OSG::SizeT for the hash code would make this play more nicely with C++11
std::hash, which uses std::size_t.

> 4.) OSGBlendChunk: In some cases glBlendEquation was used where
> glBlendEquationEXT should have be used.

-> other mail.

Thanks for the fixes!

Cheers,
Carsten

[1] hash code gets overwritten to seed,
you seem to be using the address of pixel (truncated to 32 bit) not the
content?

------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk

_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2.0 - Issues and Improvements

Reply via email to