Sdk demo rendering problem

[Bird]

I'm not sure if you're ready for feedback about Fox yet but I'm seeing some display errors when switching between sdk demos using the new toolkit. This is what's displayed after switching from "Coefficients of friction" to "Closest distance". http://www.hurleyworks.com/downloads/sdk_demo_problem.jpg

-Bird

[Julio Jerez]

wooo, tha seems wrong, I just tested in my system and it seems right.
can you please try again and see if it si still wrong? I have being check in lot of stuff this week.

btw FOX seem very nice, small, open source, object oriented, and eassy to use. what else can I wish for.
What I like is that it allow to read the inputs asynicronous frm teh main window loop, something I could not get to work with QT, not matter how hard I try.
some how Qt flush the keyboard input buffer an do not let tha client app to read key unless if is signal to a qt window.

I hope this is not a show stopped

[Julio Jerez]

It may be because of the line rendering I check in with the option off, please see if this makes it better.

[Bird]

It may be because of the line rendering I check in with the option off, please see if this makes it better

I tried with version 1290 without wireframe rendering and the problem is still there. Since it works on your system then maybe it's an opengl driver problem. I'll update my drivers and see if that makes a difference.

btw FOX seem very nice, small, open source, object oriented, and eassy to use. what else can I wish for.

I had never heard of Fox but it looks well done, easy to use and still being actively developed. I'll try to getting it running on the Mac too when I get a chance.

-Bird

[Bird]

I updated my drivers and the problem is still there, unfortunately. It looks like it's some sort of refresh problem with drop-down menu, where Fox is re-drawing only the dirty area directly beneath where the menu was opened If you can find a way to re-draw the whole screen when the menu closes I'm sure that would solve the problem. If I drag the whole app window around by the top drag bar, the display re-draws correctly when I release the mouse. I tried to record the screen to show you but it works perfectly when the recording software is running.

-Bird

[Julio Jerez]

that is strange, I just run it on my old laptop whis has xp32 intall and it ecenb use Mesa OpenGL, and it works fine.

I am sure it is something that is not quite right in my code. People do not make GUI expecting then to be use in real time applications.
if you look at the code I have a boolean that suspend refress each time a menu message is send.

Code: Select all

long NewtonDemos::onPaint(FXObject* sender, FXSelector id, void* eventPtr)
{
   if (m_doVisualUpdates) {
      // render scene
      dFloat timestep = dGetElapsedSeconds();   
      m_scene->UpdateScene(timestep);

      CalculateFPS(timestep);
   }
   return 1;
}

some how I beleive that in your system it do need to refresh when you are draging doVisualUpdates. but teh bollean is off.
I have to come up with better logic so that when dragging or when doing when you are doing, it sends a onPaint to refresh but not to advance the simulation.
can you tell me the secunce of command you are executing to make it reproduce the Bug?
I am possitive there is a Event that I am not reponding to.
this could be an AMD/NVIDIA driver thing where the NVIDA refresh because it has a copy of the frame, while the ATI losses the back buffer and copy garbage from an old frame.
bascially variable m_doVisualUpdates should be a code, that do different things based on the Message it recieves.

My old laptop is an atlhon 2500, and it does no have haeared accelration so it run OpenGL in emulation mode usin a mesa drives.
I am suprice is runs at all. but at least this GUI does not display * like all others GUI I tryed on the pass of that laptop.
If it works on that laptop, I am prety sure it works on most systems. But I like to find out what is wrong on your.

[Bird]

that is strange, I just run it on my old laptop whis has xp32 intall and it ecenb use Mesa OpenGL, and it works fine.

I'm running Vista 64 bit but using the 32bit version of the SDK demo app. I don't thnk that should make any difference but maybe it does.

The 64bit version of project_vs2008 for coreLibrary_300 doesn't compile yet because of the new paths to the "meshUtil" folder can't be found with the current 64bit project settings.

can you tell me the secunce of command you are executing to make it reproduce teh Bug?

Easy to reproduce by:

1. start SDK demo app( super car is default demo);
2. click top menu->Demos->Coefficients of friction
3. when you release the mouse, the menu disappears and the new demo(Friction) is displayed only within the region where the menu background rectangle was. The rest of the viewport shows the previous demo( super car )

-Bird

[Bird]

I have it working now on my system by adding a "swapBuffers()" call after loading the new demo.

Code: Select all

void DemoMenu::LoadDemo (DemoEntityManager* const scene, int index)
{
   scene->makeCurrent();
   m_demosSelection[index].m_launchDemoCallback (scene);
   scene->swapBuffers();  // added this line
   scene->makeNonCurrent();
}

-Bird

[Julio Jerez]

ha excelent. I added and check it.
also do you get a fluid frame rate? I notice that you fps was low.
if you test again please tell me what fps you get?

[Bird]

ha excelent. I added and check it.

I don't think it's going to be that easy. Using any of the other menus causes the same problems too. It would be nice to be able to make just 1 swapBuffers() call somewhere to handle all redraws after any menu is accessed but I can't figure out where to put the call.

also do you get a fluid frame rate? I notice that you fps was low.
if you test again please tell me what fps you get?

I was running in debug mode. Frame rates are fine .... Friction is around 1800 fps and Closest Distance is around 450 fps.

-Bird

[Julio Jerez]

that will be function onpain, I chnag eot this

Code: Select all

long NewtonDemos::onPaint(FXObject* sender, FXSelector id, void* eventPtr)
{
   if (m_doVisualUpdates) {
      // render scene
      dFloat timestep = dGetElapsedSeconds();   
      m_scene->UpdateScene(timestep);

      CalculateFPS(timestep);
   } else {
      m_scene->makeCurrent();
      m_scene->swapBuffers();  // added this line
      m_scene->makeNonCurrent();
   }
   return 1;
}

see if that make it better.


our video cars are very differents.
In mys syetm the fritionsi 3500 fps, bu the closet distance is 79. My video car car somehow * at drawing lines.

[Julio Jerez]

Opps I take the comment back. in reality it is not that, it is that I has not optimized the closest distance for convex cast on compound collision is is in fact doing a brute force cast on all shapes.
I will put that on my list of things to do.
It is doing 9 x 40 = 360 cast when it should be doing about 9 * 4 0r 5 cast ~= 45
basically it shoud be at leas 3 or 4 time faster, and much faste on more complex compounds.

[Bird]

that will be function onpain, I chnag eot this

Code: Select all

long NewtonDemos::onPaint(FXObject* sender, FXSelector id, void* eventPtr)
{
   if (m_doVisualUpdates) {
      // render scene
      dFloat timestep = dGetElapsedSeconds();   
      m_scene->UpdateScene(timestep);

      CalculateFPS(timestep);
   } else {
      m_scene->makeCurrent();
      m_scene->swapBuffers();  // added this line
      m_scene->makeNonCurrent();
   }
   return 1;
}

see if that make it better.

No, that doesn't help. I put a break point at m_scene->makeCurrent() and it doesn't get called after Demos, Options or Help menu activity. It does get called on File->Load but I get this after the Load menu closeshttp://www.hurleyworks.com/downloads/refresh_problem.jpg

-Bird

[Bird]

I was running in debug mode. Frame rates are fine .... Friction is around 1800 fps and Closest Distance is around 450 fps.

In the latest svn 1304, Friction is running at around 2200fps and Closest Distance is around 750 fps ... and that's with 1 micro-thread and no Simd.

Nice!

-Bird

[Julio Jerez]

Yes, closest distance on compound had a brute force implementation, but since I started to add continues collision, as I am writing the version of the support functions I can complete some of those.
closest distance for compound required a function that I had not re-writen yet, so I used a brute force aproace of testion all sub shapes.
with the new implementaion is more than twice as fast, and this is because the part of the bessel have a high range of overlaping convexes.
as the number of convex is more separated then the number of test assimtotically aproach the shapes in the vecinity. in effect making it constanst time test.

for example now that we have convex decomposition whi generate very nice convex partitions arrays, the funtion sodul eb very efficient.
I am doing the continue collision now because convex decomposition can generate small convex and they may penetrate other shapes and get stuck. so continue collision is needed.
continue collison in 300 will be far more ropbust than it was in any other previus versions.