date:20080528

Re: [osg-users] Parallel Split Shadow Map (Update)

2008-05-28 Thread Adrian Egli OpenSceneGraph (3D)

Hi Robert,

At the moment the 23 May version is ready for submission :-). So you can
update this version in SVN.

cheers
adrian

2008/5/27 Robert Osfield [EMAIL PROTECTED]:

 Hi Adrian,

 I have run out of day, in my day long merge spree, so I'll need to
 start up again tomorrow, at which point I'll check out your latest
 changes.   If you have any further updates to the ones sent of the
 23rd May please just send them through,

 Cheers,
 Robert.

 On Fri, May 23, 2008 at 8:11 AM, Adrian Egli OpenSceneGraph (3D)
 [EMAIL PROTECTED] wrote:
  Latest Version to Test, i tested this on:
 
  ATI X1600 M : Windows Vista
 
  osgshadow --pssm --SingleThreaded --screen 0 -3
 
 
  2008/5/21 Adrian Egli OpenSceneGraph (3D) [EMAIL PROTECTED]:
 
  Hi all again,
 
  now i came from ATI X1600M test, same artifact as you described, small
  shadowed line. i will try to figure out where it comes from. i guess we
 have
  to set another polygonoffset. 0.5,0.5 is may not as good as it seams to
 be.
  may -0.5,-0.5 or -1.0,-1.0 will work for ATI and NVidia. please check
 this
  with the option
  for polygonoffset and tell me what is a good offset.
 
  thanks adrian
 
  2008/5/21 Ralph Kern [EMAIL PROTECTED]:
 
  Adrian Egli OpenSceneGraph (3D) schrieb:
 
  Hi all,
 
  i still come around with some changes. :-) now the near - far clip
 plane
  are more optimized, but i hope it's shows still correct shadows for
 all of
  your test cases.
 
  Its updated with latest PSSM version (from this morning,MEZ)
 
 
 http://webaddon3d.assoftware.ch/AE/PSSM_SHADOW_TEST_OpenSceneGraph_WIN32.rar
  (use the demo.bat)
 
  and in the attachement you will find the latest source.
 
  test
  osgshadow --pssm --SingleThreaded  --no-base-texture
 
 
 
  just checked again. I removed the other two REM's on PATH and
  LIBRARY_PATH to get the program running.
 
  Works on WinXP SP2 GeForce FX5700, but slow frame rate (2.3 fps).
 
  On WinXP SP2 ATI X1600 dual monitor the park scenes run fine using
 screen
  0 with 70 fps. There is a small lit line ( 1 pix wide) around the
 buildings
  like a self shadow offset which is to large. Chess scene is still
 entirely
  black.
 
  regards Ralph
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 
  --
  
  Adrian Egli
 
 
  --
  
  Adrian Egli
  ___
  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




-- 

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

Re: [osg-users] Openthreads problem on 64 bit windows system.

2008-05-28 Thread Adrian Egli OpenSceneGraph (3D)

Hi nelson,

i remeber a problem i got long time ago with openthreads and windows, even
on a 32 bit system. i located that we go an issue on windows system with the

sleep method. (windows native).

so can you try following:

(1) replace the microsleep with the
OpenThreads::Thread::YieldCurrentThread()
 report what happens

(2) replce the microsleep only in the Thread class / method with
YieldCurrentThread
 report what happens

if both test are also negative, then replace microsleep with
void millisleep( unsigned int milliseconds )
{
# ifdef _MSC_VER   // If its Visual C++ call Win32 Sleep function
   ::Sleep( milliseconds);
#else  // Else assume a UNIX/Linux system with nanosleep function
   timespec ts;
   ts.tv_sec = milliseconds / 1000;
   ts.tv_nsec = (milliseconds - ts.tv_sec*1000) * 100;
   ::nanosleep(ts, NULL);
# endif
}
what happens ?


Have also a look into:
and search in google with adrian egli / openthreads / sleep
http://www.openscenegraph.org/projects/osg/changeset/5313



2008/5/28 Cysneros, Nelson SPAWAR [EMAIL PROTECTED]:



 I'm having a problem with an existing application that runs well on a
 32-bit windows XP (VS 2003) system, but does not seem to work when ran
 on a 64-bit windows XP (VS 2003) system.

 I narrowed down the problem to Openthreads, seems that my threaded while
 loop never (or rarely) gets called.  I was able to recreate the problem
 with this simple program below. It runs two threads, both printing a
 message to the screen.  Only one message is displayed on a 64bit
 machine.  I turned on OSG notification to DEBUG, but no extra
 information is displayed.

 Has anyone else experience this problem?  Am I doing something wrong?
 Thanks in advance.


 ///
 //Header file MutexTest.h
 ///
 #ifndef __MUTEXTEST_H_
 #define __MUTEXTEST_H_

 #include OpenThreads/Thread
 #include OpenThreads/Mutex
 #include OpenThreads/Barrier
 #include OpenThreads/Block
 #include OpenThreads/ScopedLock
 #include iostream

 class MutexTest : public OpenThreads::Thread
 {
  public:
  MutexTest();
  ~MutexTest();
  //Functions
  virtual void run();
  void quit();
  void printHello();
  void setMutex(OpenThreads::Mutex* newValue);
  OpenThreads::Mutex* getMutex();

  private:
mutable OpenThreads::Mutex*  _mutex;
  };
 #endif


 ///
 //Source file MutexTest.cpp
 ///

 #include MutexTest.h

 MutexTest::MutexTest(){
_mutex = new OpenThreads::Mutex();
 }

 MutexTest::~MutexTest(){
std::coutMutexTest Test Shuting
 down.std::endl;
 }

 void MutexTest::setMutex(OpenThreads::Mutex* newValue){
_mutex = newValue;
 }

 OpenThreads::Mutex* MutexTest::getMutex(){
return _mutex;
 }

void MutexTest::quit() {

}

void MutexTest::printHello(){
OpenThreads::ScopedLockOpenThreads::Mutex
 lock(*_mutex);
std::cout-- Mutex Class: Hello --std::endl;
}

void MutexTest::run() {
   while(true){


 //
   //This only gets called once when running on 64bit
 system

 /
printHello();
//sleep
OpenThreads::Thread::microSleep(5000);
}//while
}//run

 //
 
 ---
 //
 //   main
 //
 //
 
 ---
 int main(int argC, char* argV[])
 {
//Create a mutex we can share
OpenThreads::Mutex* mutable my_mutex = new OpenThreads::Mutex;
MutexTest* testMutex = new MutexTest();
testMutex-setMutex(my_mutex);

//Start thread
testMutex-start();

while(true)
{
OpenThreads::ScopedLockOpenThreads::Mutex
 lock(*my_mutex);
std::cout Main: Hello std::endl;
//sleep
OpenThreads::Thread::microSleep(2000);

}//while
return 0;
 }//main
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




-- 

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

Re: [osg-users] Parallel Split Shadow Map (Update)

2008-05-28 Thread Can T. Oguz

Hi All,

I'm not sure if it's commercially fair to talk about but I need to know your
personal choices. Which graphics hardware is considered to be flawless and
most compatible with OSG? (to be used with Windows XP and Intel
architecture)

Thanks for the patience,

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

Re: [osg-users] LiSPSM contibution ?

2008-05-28 Thread Adrian Egli OpenSceneGraph (3D)

http://appsrv.cse.cuhk.edu.hk/~fzhang/pssm_project/

*Question: In which directions, we can further improve PSSMs?
*

*Answer:* PSSM+VSM http://forum.beyond3d.com/showthread.php?p=975976
(variance
shadow maps http://www.punkuser.net/vsm/) and PSSM/CSM+LiSPSM (light space
perspective shadow maps) might be better ways to further improve PSSMs. A
good example for PSSM/CSM+LiSPSM is the professional game Lost
Planethttp://www.lostplanet-thegame.com/flash_index.php,
refer to the discussion
herehttp://forum.beyond3d.com/showpost.php?p=919807postcount=116for
more information (just use Ctrl+F to find Fan Zhang on the page).
For
your convenience, I post the PSSM/CSM related part in the discussion below,

* *
http://www.watch.impress.co.jp/game/docs/20070131/3dlp91.htm
http://www.watch.impress.co.jp/game/docs/20070131/3dlp92.htm * Glitch in
LiSPSM http://www.watch.impress.co.jp/game/docs/20070131/3dlp91.htm*
* Cascade-extended
LiSPSM http://www.watch.impress.co.jp/game/docs/20070131/3dlp92.htm*

Furthermore, since the shadow-map alignment depends on the light-view
configuration, the shadow boundaries might flicker as the viewer moves.
See a movie here
(.avi)http://appsrv.cse.cuhk.edu.hk/%7Efzhang/pssm_project/flickering.avito
show this problem. For this problem, when using a shadow map size over
1024 and the number of splits is greater than 3, this phenomena can be
nearly eliminated with PCF/VSM. Another possible solution is used in Terry
Welsh's OpenSceneGraph-based
implementationhttp://appsrv.cse.cuhk.edu.hk/%7Efzhang/pssm_project/PSSMdemo_OSG_Terry.tar.gz,
which moves the light projection in *x* and *y* coordinates in a texel size,
so you are always having the same aliasing pattern. However, when you change
the size of the projection (i.e. the *min* and *max* vectors in the
*crop*matrix in Oskari
Nyman's DirectX9
implementationhttp://appsrv.cse.cuhk.edu.hk/%7Efzhang/pssm_project/PSSMdemo_DX9.zip),
this problem still happens. Anyway, as I mentioned, this issue is not
noticeable at all if we use PSSM+PCF/VSM.

The last issue might the performance. I've to say, as the tremendous
advances in modern GPUs, even without hardware-acceleration, PSSMs could
achieve a high fps in practical applications. In our Gems 3
paper/implementation, we proposed the acceleration methods on DX9-level and
DX10-level GPUs. Please check this page back later. In summary, personally,
I don't think the performance is a problem for PSSMs on modern GPUs.
*
Alors, OSG take same way?

who could support me ?

regards *

2008/5/27 Wojciech Lewandowski [EMAIL PROTECTED]:

Hi J-S,

Yes it is view dependent. Have you seen some issues with pure
osgShadow::ShadowMap in multi view configurations ?

Not at all, I was just curious since you said StandardShadowMap is
equivalent to osgShadow::ShadowMap - but the former is view-dependent where
the latter is not.

I thought about it for a while when I was struggling with multi view /
multi threaded OSG on XP. Threre exists some remote possibility for
osgShadow::ShadowMap to fail in threaded modes. Just an example: multicore
default DrawThreadPerContext uses two SceneViews in parallel. While first
does draw for previous frame, second does cull for next frame. Teoretically
second SceneView may invoke ShadowMap::cull which could alter shadow TexGen
matrices before first SceneView managed to use it for generating shadow tex
coords. This would produce shadow texture misalignment and possible flicker
between scenes. But in practice I doubt anyone would be able to notice it.

You may try to add setMinLightMargin( 10 ); in osgshadow paragraph
where --lispsm technique is created. There is a catch though. You may be
hit
by some assertion code I added today. If you want to try this please
update
ConvexHull.h header (attached here).

Yep, that solves it. Interesting, so there's a few more parameters to
tweak depending on the scene.

These techniques have some limitations and may not be interesting for
eveyone. Techniques were created for vis simulation scenarios where
databases are usually larger than view frustum (considering their bounds)
and implicitly assume that all objects can cast shadows on themselves. So I
assume that shadow casting and shadow receiving scenes are basically the
same. I think that other MinimalXXShadowMap could be created to take
advantage of the situation where shadow casting and shadow receiving scenes
differ. LisPSM would not require changes. All what would be needed is to
derive it from this new base class.

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

52 matches

Mail list logo